Jump to content
The Dark Mod Forums

Script Editor Gui Thingy


Recommended Posts

Hey guys, I was speaking with Andreas Scholz. He is the author of the D3, Quake 4, Prey, Script editor. I'm exploring the possibility of integrating this functionality into DR, I think it has the potential to be a very powerful tool for Dark Mod mappers.

 

If you haven't had a chance to check out the tool yet, it's here.

 

http://www.sdlaunch.de/download_eng.php

 

I'm just waiting to get an email address from Andreas. Would one of you be willing to drop him a line to see if his source code would be helpful, or if he might be able to help us use it in some way? It's something I would like to see in DR, much like the T3 scripting tool...but I don't want to burden you guys with too much work getting it in there.

Link to comment
Share on other sites

We could certainly add a shortcut to launch the application from DarkRadiant. We could also do some "intelligent" processing of the map name, so that a blank script could be created for the current map, or the existing map script located by name and opened in the editor.

 

Trying to achieve any tighter integration that this would be unlikely to succeed, however. I would be willing to bet that he is not using GTK, and even if he were it would not be possible to "merge" the code in any meaningful way without doing more work than if you just wrote a new feature from scratch.

Link to comment
Share on other sites

But wouldn't it be possible to have some type of a script editor built right into DR, much like stim/response editor and objectives? I'm kind of in the dark on how all that works of course. :) Usually when I think something would be rather easy to implement, I'm totally wrong. :)

 

I didn't think it would be possible to plug his program directly into DR and have it work, but I was more interested in adding the functionality directly into the editor. In editor scripting would be pretty sweet.

 

We can have a chat with him at any rate, his contact information is here.

 

foren@sdlaunch.de or ICQ#: 9859227

Link to comment
Share on other sites

But wouldn't it be possible to have some type of a script editor built right into DR, much like stim/response editor and objectives? I'm kind of in the dark on how all that works of course. :) Usually when I think something would be rather easy to implement, I'm totally wrong. :)

 

Stim/Response and Objectives are very limited in domain, mostly this is just a matter of setting certain keyvalues on certain objects based on a GUI presented to the user (I think -- I haven't started either of these yet so they may prove more complex).

 

Scripting, on the other hand, is totally open. It is basically like writing C++ code to go alongside your map, which could do almost anything (depending on the limitations of the exposed API calls). All you can do to simplify scripting is to provide a nice text editor with syntax highlighting and suggestions of known language constructs (which from the screenshots it looks like this program is doing), unless you provide a list of somewhat inflexible prewritten scriptlets like T3Ed does.

 

If we wanted the first option, by far the best thing to do is to shell out to this external program rather than trying to re-implement the functionality within DR (feature bloat alert). The second option could be investigated if there was a suitable set of prewritten scripts that mappers often needed to use, and an appropriate way to integrate such scriptlets into the current map (not impossible, but it could be time consuming).

Link to comment
Share on other sites

If we ever would like to implement an additional scripting, then we should go for some existing language like Java, Perl or Python. Beside that I don't really see a good reason what advantages this would have, or do I miss the point? And if it is just to have an editor, well, I think most programmers already have a good editor that goes with their programming, and personally I prefere to use these, unless there are very good reason to learn yet another specialized editor.

 

What would be much more interesting, would be a sourcelevel debugger for the scripting engine. This could really help, because currently debuggiong scripts is quite painfull.

Gerhard

Link to comment
Share on other sites

Mainly what I would like to see, in the future, is the ability to have a T3Ed style scripting system, using 'scriptlets' as Orbweaver cleverly named them. :) I don't expect our current members to work on this, as you're stretched thin as it is...but I would like to recruit someone. Where I would like to break free from the T3Ed scriptlets, is the ability to create custom scriptlets and save them for future use...and then share them with other mappers. While the T3Ed scripting system was very powerful, you still hit a lot of brick walls and the ability to create custom scripts would have unleashed the full power of level making. I'm going to try and recruit someone from the T3Ed community to work on this specifically for us as a side project I think. So perhaps we'll hold off on contacting this guy. I don't want to turn DR into bloatware, but I would like to push for more user friendly scripting. I want the best of both worlds, pros can write scripts to their hearts content and newbs can mix and match existing scripts with a T3Ed style gui.

 

I'm going to start fishing. You'll have to indulge me on this one. :)

Link to comment
Share on other sites

If we ever would like to implement an additional scripting, then we should go for some existing language like Java, Perl or Python. Beside that I don't really see a good reason what advantages this would have, or do I miss the point?

 

I think the idea was that point-and-click selection of script parameters in the editor would spit out the respective Doom script to go with the map in order to implement the user's selection. There was no question of replacing the scripting engine within Doom 3 itself.

 

I don't have a problem with what New Horizon is aiming for from a conceptual point of view, just as a programmer I cannot see any obvious way to implement it in an efficient and flexible manner (although there may well be an obvious solution which just hasn't occured to me yet). In particular, if we were to embark on this in any way I would want to be absolutely sure that all possibilities to use targets and links between in-game objects were exhausted -- as I recall Dromed was capable of amazing things just by connecting objects together in the map itself.

Link to comment
Share on other sites

I like the idea of having a point-and-click interface; I don't think that most mappers are programmers.

 

I do think it would have to be carefully designed though.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

I do think it would have to be carefully designed though.

 

Extremely. :)

 

I think we could look to T3 for the types of 'pre-made' scriplets they had and we could make our versions of them. You could definitely do a hell of a lot with that tasty little point and click t3 scripting system. If it's possible for people who know the scripting language to add more to it...we could easily see some really neat things in missions that would otherwise be overly simplistic. I'm not a programmer, that much is certain, and I don't intend to learn any great amount of doom 3 scripting to build my levels. I would either have to get someone else to do it...or use a T3Ed like system. :)

Link to comment
Share on other sites

There is also this editor named Raptor (screenshot). According to its homepage it has syntax highlighting, ballon help and and entity list, but I haven't touched this thing. It appears to be closed source and the homepage of this thing is down, so maybe this project has died away (as it took the author two years from announcement to beta).

 

What I would consider a useful feature is an automatic copy of the script file being saved when saving the map under a new name.

 

Perhaps we should look for any GTK2+ open-source editors that we can base our work on, but I believe this will be a time-consuming task in either case.

Link to comment
Share on other sites

If it just provided syntax highlighting and similar niceties, I don't think it would be worth the effort. Any plain text editor works just fine, and if you get a decent one (Notepad++, TextPad, and there are many others) you can define your own syntax highlighting without having to write code; just tell the editor that .script files are like C files but with a different set of keywords. It's pretty easy to do it for TextPad, for example; just create a plain text list of keywords, and mess around in the options to set it up.

 

That is one wheel that really does not need reinventing again. :)

 

What might be worth it is a point-and-click editor, similar to T3Ed's script editor (or like Klik'n'Play, if anyone's used that - it's the same kind of thing).

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

I think we can probably all agree that if any such feature is to be implemented, it should be a point-and-click editor similar to T3Ed rather than Yet Another Fancy Text Editor. The question is, how to implement this?

 

It might be helpful if we had a list of examples from T3Ed, alongside the equivalent DoomScript code that would implement each example in Doom 3. Unfortunately I have never done any scripting in either T3Ed or Doom so I have a somewhat limited understanding of the requirements.

Link to comment
Share on other sites

It might be helpful if we had a list of examples from T3Ed, alongside the equivalent DoomScript code that would implement each example in Doom 3. Unfortunately I have never done any scripting in either T3Ed or Doom so I have a somewhat limited understanding of the requirements.

This should give you (and anyone else who wants to look at it) some idea:

 

http://www.ttlg.com/wiki/index.php?title=T...script_tutorial

 

It might be useful to go through the conditions and actions in the T3Ed scripting reference (linked to from there) and see which of them have straightforward translations to Doom 3 script. Actions and QUERY conditions should be translatable into D3 script directly; the WHEN conditions might not all have suitable equivalents though.

 

There are some examples dotted around that wiki too:

 

http://www.ttlg.com/wiki/index.php?title=D...nscious_or_Dead

http://www.ttlg.com/wiki/index.php?title=A...Inventory_Items

http://www.ttlg.com/wiki/index.php?title=Underwater_Vision

...etc.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

Yup, point and click is exactly how this should work. I'll post some screens of various things in the T3Ed version.

 

I am also trying to see if any of the former devs on ttlg are still in contact with any of the coders who might have built the T3Ed scripting GUI. If they could be brought on board as a consultant of some sort, it would certainly help us out.

 

Edit:

 

Here we go. This is the general flow of scripting in T3Ed for anyone who hasn't seen the scripting GUI and doesn't know the flow. It's a good system and it makes advanced actions easier for newb and pro alike...allowing the FM author to focus on the mission, rather than having to learn yet another skill that will delay mission release.

 

Trigger script manager, where all the finished scripts are stored for later use.

314919442_8a63fa68dd.jpg

 

We click New to create a new script, and give our script a distinct name.

314919440_9fcde30b52.jpg

 

We then combine as many Conditions

314919437_72643ee2d6.jpg

 

...and actions, as it takes to meet our requirements.

314919435_0203d9453b.jpg

 

Our new script is then saved to the Trigger Script Manager for use in later missions.

 

314919444_13fe8cf0cd.jpg

Link to comment
Share on other sites

it makes advanced actions easier for newb and pro alike

Actually, personally I really, really dislike it. I find it slow and ugly and very limiting (not to mention buggy). But that's because I'm a programmer. :P I can definitely see the value for people who aren't, but I really really wished that T3Ed had a proper scripting language as well as the GUI.

 

Thankfully Doom 3 already does have a proper scripting language, so we can't have that problem. :)

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

Actually, personally I really, really dislike it. I find it slow and ugly and very limiting (not to mention buggy). But that's because I'm a programmer. :P I can definitely see the value for people who aren't, but I really really wished that T3Ed had a proper scripting language as well as the GUI.

 

Thankfully Doom 3 already does have a proper scripting language, so we can't have that problem. :)

 

It's definitely buggy, and crashy...but the general usage is good. When it works, it works. As a non-programmer...I found it really great to use. Doom 3 gives us the best of both worlds though. :)

Link to comment
Share on other sites

The objectives editor should allow some basic scripting things to be done by setting up some invisible objectives, that call scripts or trigger things when completed. Also, the stim response system. The trigger system also allows for some basic functions. I would think a GUI editor is fine as a standalone, but spending a lot of effort to integrate it with the editor might not be our highest priority.

Link to comment
Share on other sites

Once you have created one of these T3Ed scripts, what do you do with it? As in, what sequence of actions causes the script to be run?

 

Some of those examples look possible, however it is necessary to divide the "CONDITIONS" into things that HAPPEN (such as an object is frobbed, or a stim goes off), and things that are TRUE (such as the player having a certain number of hitpoints or holding a certain object). For simplicity, it would probably be necessary to constrain scripts to have a single trigger event (something that happens) but multiple conditions (things which are checked to be true after the trigger goes off).

 

Some complexity will arise because, depending on the trigger event, the script might have to be written in a different way. For example, if the trigger is "When object is frobbed", the script would have to be a frob-action script, whereas if the trigger "When object X emits stim Y", the script would have to be implemented as a stim-response.

 

An alternative would be to ditch the trigger events entirely, and require that scriptlets have to be called explicitly by another action. For example, a scriptlet "OpenMainDoor" could check whether the door was open, start the necessary rotation/translation and change the lighting, but it would have to be linked explicity via a frob-action on the door.

Link to comment
Share on other sites

Once you have created one of these T3Ed scripts, what do you do with it? As in, what sequence of actions causes the script to be run?

You assign it to an object. Then, when the appropriate trigger(s) happen (how this works varies depending on the trigger conditions - it could be frobbing, or an AI alert change, etc.), T3 checks the conditions (some of which refer to a "this object", which is the object the script is assigned to). If they are met, then it processes the actions, in order (some of these also refer to the "this" object).

 

Some of those examples look possible, however it is necessary to divide the "CONDITIONS" into things that HAPPEN (such as an object is frobbed, or a stim goes off), and things that are TRUE (such as the player having a certain number of hitpoints or holding a certain object). For simplicity, it would probably be necessary to constrain scripts to have a single trigger event (something that happens) but multiple conditions (things which are checked to be true after the trigger goes off).

Yeah. This is exactly what T3 did, although it wasn't made very clear; both triggers and queries (Krypt called when "WHEN" conditions and "QUERY" conditions respectively) were lumped together as "conditions", when really they were very different things. It would make more sense to have three sections; "triggers" (e.g. frobbing), "conditions" (e.g. is the door currently open?), and "actions" (e.g. close the door).

 

BTW, if you didn't notice, there's another level of complexity because it supports boolean conditions; you can OR together two or more trigger conditions and it will trigger if any one of the triggers occurs. You can also AND multiple conditions together - it's pretty useless for trigger conditions (because all the triggers must happen in the same frame for the script to be invoked) but you can use it for "query conditions", which is useful.

 

There's an implicit top-level AND too (so if you have multiple conditions listed, all of them must be true / get triggered - pretty obvious but I thought it worth mentioning).

 

An alternative would be to ditch the trigger events entirely, and require that scriptlets have to be called explicitly by another action. For example, a scriptlet "OpenMainDoor" could check whether the door was open, start the necessary rotation/translation and change the lighting, but it would have to be linked explicity via a frob-action on the door.

Well, it's just a different way of looking at it. T3's method would "link" the door frobbing to the OpenMainDoor script by having an instruction in the script itself; your alternative would move that instruction to somewhere external to the script. The difference is not huge.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

BTW, if you didn't notice, there's another level of complexity because it supports boolean conditions; you can OR together two or more trigger conditions and it will trigger if any one of the triggers occurs. You can also AND multiple conditions together - it's pretty useless for trigger conditions (because all the triggers must happen in the same frame for the script to be invoked) but you can use it for "query conditions", which is useful.

 

The shouldn't be a problem, because the conditions would be written into the script. For example, if you created a script

 

WHEN: Object is frobbed

IF: Gametime > 300 AND PlayerHitPoints > 80

ACTION:: Set objective X to COMPLETE

 

the autogenerated script would look something like this (ignoring the fact that I know nothing about the available statements or hiw gametime, hitpoints and objective-setting are handled):

 

void object_1_frobbed() {
if (sys.gametime > 300 && player.hitpoints > 80) {
	setObjective(X, COMPLETE);
}
}

 

Then, because the trigger action is "frobbed", this script would be set as a frob-action on the relevant object.

 

Well, it's just a different way of looking at it. T3's method would "link" the door frobbing to the OpenMainDoor script by having an instruction in the script itself; your alternative would move that instruction to somewhere external to the script. The difference is not huge.

 

The difference is more than cosmetic, because the Script Editor has to decide what to do with the autogenerated code. If the editor is aware of the different trigger conditions, it needs to decide how to link the new script into the level, by setting as a frob-action, stim-response, objective or whatever. If it has no awareness it can just dump the named script into a file and let the user connect up the calling sequence himself.

Link to comment
Share on other sites

The shouldn't be a problem

No, it's not a problem. Just something to be aware of when implementing.

 

The difference is more than cosmetic, because the Script Editor has to decide what to do with the autogenerated code. If the editor is aware of the different trigger conditions, it needs to decide how to link the new script into the level, by setting as a frob-action, stim-response, objective or whatever. If it has no awareness it can just dump the named script into a file and let the user connect up the calling sequence himself.

True. The latter might be preferable (since it's undoubtedly easier to implement), provided there's still a GUI for mappers to do it with. Ideally you wouldn't have to touch a line of code when using the GUI script editor, and the scripts it generates.

 

I don't know how exactly that would work, though, since I have no idea how to call scripts via frobbing/stims/etc.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

True. The latter might be preferable (since it's undoubtedly easier to implement), provided there's still a GUI for mappers to do it with. Ideally you wouldn't have to touch a line of code when using the GUI script editor, and the scripts it generates.

 

That's my feeling too. The Script Editor creates the scripts, which the mapper then has to link with whatever objects need to call them (which, as you say, could be done with other GUIs, such as the Stim/Response editor which could autopopulate the list of responses with known scripts).

 

I don't know how exactly that would work, though, since I have no idea how to call scripts via frobbing/stims/etc.

 

That's my problem as well. I know next to nothing about Doom 3 scripting and next to nothing about how the current incarnation of TDM uses scripts. This feature will require very tight integration with the mod if it is to work effectively (I would hazard that the available actions/conditions in T3Ed were actually hard-coded into the game engine).

Link to comment
Share on other sites

As to where to put the script for something frobbed and something stimmed, that's pretty easy. It takes 2 steps though:

 

1. Define the frob script in the object's def (key/value pair list)

I.e., set the following key/value on the entity:

 

"frobaction" "<name space>::<my frob script>"

or

"response_fire" "<name space>::<my response script>"

(and I think some other things might need to be set for stim/response, I forget)

 

2. Generate the actual script.

We've tried to make the systems pretty flexible, so that the script can be input as a method on that particular entity scriptobject (if it has one), or if it doesn't, it can go in the global namespace or the map namespace. I think for this purpose, the map namespace will be best. Otherwise you'd have to generate a scriptobject for the entity and point to that scriptobject in the key/values, and some entity types don't support scriptobjects. Overall, it would be less of a pain to just create the method in the map namepace.

 

The only other issue is that the SDK code that calls the 'frobaction' and 'response_*' script methods expects those methods to have certain arguments (what is being frobbed if it's a global method, who has done the frobbing or stimming, etc), so you'd have to make sure the generated method accepts those arguments.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 1 reply
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...