Nyarlathotep's Application Thread

[Nyarlathotep]

I was hoping there was a non-Microsoft dependent way... Crap. Well, I've got to go through the obligatory reboot before I can finish setting up Micro$oft Migraine C++.

 

Btw, how would you tell if something is exposed to scripts, and if not, how would you add it (other than custom console commands)?

[Crispy]

Things like that would have to be exposed to scripts via "scriptevents" (the term they use for functions in the SDK that can be called directly from scripts). I linked to the standard Doom 3 scriptevents before; if you don't see it in that list, it's probably not possible (or the list is out of date).

 

As for making them, there's a scriptevent system that you can hook into by providing certain definitions... search the SDK for idEventDef to find examples of scriptevent definitions that you can use as a template. It's fairly straightforward. You just create a method that you want to call, and add a couple of lines of code to make it available to scripting. Then you'd add the declaration of the method to doom_events.script (or darkmod_events.script in our case - we keep our custom ones separate to make it easier to apply potential future SDK updates). If you want to return a value from a scriptevent you have to do it in a special way, by calling e.g. scriptThread.returnInt(6) to return the number 6.

[Nyarlathotep]

I love how the ModWiki includes absolutely nothing on how to add new script events. Thanks, Crispy.

[sparhawk]

There should be something IMO. I go and check it. Hmmm... The SDK entries are pretty useless IMO. I think I will write something in the next few days. Looking through the SDK shouldn't be to hard though.

 

The major classes, like idEntity, etc. are all prepared for having script interfaces. If you want to add a new event to such a class, just look at the top of the sourcecode. There are defines like this:

 

const idEventDef EV_Player_PlayStartSound( "playStartSound", NULL );
const idEventDef EV_Player_HoldEntity( "holdEntity", "E", 'f' );
[/code

which defines the script function name and it's parameters.

playStartSound doesn't have any paramters and returns nothing. holdEntity has a paremter an entity, and returns a float. All numbers in scripting are considered of type float from the scripting side, even when they are ints in the SDK. You still have to treat them properly though. 

A little below this comes a line like this:
[code]
CLASS_DECLARATION( idActor, idPlayer )
...
EVENT( EV_Player_PlayStartSound,		idPlayer::Event_PlayStartSound )
EVENT( EV_Player_HoldEntity,			idPlayer::Event_HoldEntity )
...

END_CLASS

 

This maps the event function from above, to the actual class function that should process it. That's it.

 

You also have to add the function to the doom_events.script as a prototype. If not D3 will not know about it if you try to call it. If you add a functionname there, but it is not avilable in the SDK code, then D3 refuses to start at all.

[Ishtvan]

How is everything going so far?

 

If writing a script event is turning out to be a pain, it's not strictly necessary for this. You can use gameLocal.printf("<string>") to print directly to the ingame console for testing, then use that and check an example key, maybe print out when it has started to be held down and when it is released. You may need to check this in the player frame loop, which is idPlayer::Think. (This gets called once per frame every game frame).

 

I think it would be good if you could just put up that example code for doing the following: Suppose the player binds "frob" to an impulse, call it IMPULSE_42. Now, how do we detect later when that forb key is held down, and when it is released?

 

						// Returns key bound to the command
virtual const char *		KeysFromBinding( const char *bind ) = 0;

					// Returns the binding bound to the key
virtual const char *		BindingFromKey( const char *key ) = 0; 

					// Directly sample a button.
virtual int				ButtonState( int key ) = 0;

					// Directly sample a keystate.
virtual int				KeyState( int key ) = 0;

 

We really need to know how these methods work. For example, where does the "bind" get named? Is that the string you would enter into the bind console command, like "_impulse42", or did they do something different with that in the new SDK?

 

Also, if we want to sample this keystate later, how do we know which "int key" argument corresponds to which key? KeysFromBinding seems to return a string. How do we go from that to the int that we have to put in KeyState? It seems like there is another function missing that would take the string key (e.g. "kp_pgdn") and convert it into an int key for KeyState(), unless it is just atoi'd.

 

It would be really helpful if you could figure out and document just those things for starters.

[Nyarlathotep]

I've had to put it off until now because of a school project. I apologize for the delay, but it couldn't be helped. My main reasoning behind using a script event was to ensure a faster turnaround in the testing phase. Look for a progress update sometime tomorrow.

[Ishtvan]

Cool, I'm not trying to rush you or anything, just wanted to see if you had any questions. Sometimes people get stuck on one thing, get frustrated, don't ask anyone for help and then disappear.

 

What I did in the previous SDK was write a console command that waits for the next key and prints out what it was, but then you'd have to learn how to add a new console command. Whatever way you think is best to test it is fine, I just wouldn't spend too much time setting up an elaborate test as we'll have to adopt it to our modified codebase anyway. The main thing is just figuring out the handle for a key that goes into that KeyState or ButtonState function.

[Nyarlathotep]

Sorry about not updating until now, but I was rather distracted and couldn't get to work until today. I've run into a few issues already.

 

For starters, I can't tell whether or not I've successfully bound a key to BUTTON_5 or IMPULSE_42 (two proof of concept bindings I set up to test that I could do anything at all). Specifically, bind doesn't give any success message, only errors, nor am I capable of generating any output to determine my success. Whenever I press a key I've bound to one of the two, either I cannot print to console with common->Printf() or gameLocal.Printf(), or I can't get Doom 3 to actually use BUTTON_5 or IMPULSE_42. Fuck!

[Ishtvan]

When you bind to a key in the console, I believe it needs an underscore before it. E.g. "bind <key> _impulse42" or "bind <key> _button5". You could test if the key you're binding successfully by binding some known impulse like switch weapons or something. (The list of impulses can be found in a ginat switch/case in /src/game/player.cpp)

[sparhawk]

The easiest and most reliable way is to write a simple global variable in the game_local startup and create a file somewhere. Then you can use this file to write status messages. That's how I usually verify that some function is called, when I don't find a better way or don't know if it works. Since this is only for testing it would be small and simple.

[Nyarlathotep]

Apparently, the problem is that I can't actually get the damn thing print to console when I activate the script. Checking IMPULSE_1 and BUTTON_ATTACK show that I was binding them right, but the code is displaying them. What the hell is going on?

[Nyarlathotep]

Further issue. Just to be sure, I added a common->Printf() to the beginning of idPlayer::think() and gameLocal.Printf() to the end. I can't get Doom 3 to print anything at all!

[Crispy]

Are you sure that Doom 3 is loading your compiled gamex86.dll?

 

Try putting it in the same directory as doom3.exe. That should force D3 to use it.

[Nyarlathotep]

Thanks. That was a real headache.

 

 

 

Edit: I just remembered that all of this bullshit was just trying to prove to myself that I could do buttons and impulses. I haven't even started on the real work. ...I suddenly feel that headache coming on again.

[Nyarlathotep]

Could somebody explain to me how to print to the hud? It's a lot easier to figure out what's going on when you can see it changing dynamically.

[Crispy]

Check this out: http://a.parsons.edu/~evan/d3cc/Text%20Mes...20Part%202.html

 

This is from a series of SDK tutorials which are linked to from here. They're pretty useful, so it's worth bookmarking that topic. (Though I haven't actually read all of them.)

 

It occurs to me that we should probably be archiving these on our wiki.

[Nyarlathotep]

Thank you! The Doom 3 wiki doesn't have a working link to tutorial 4! I LOVE YOU SO MUCH!!!

[Nyarlathotep]

Interesting. Experimenting with ButtonState(int key) reveals some interesting features. First off, ButtonState(int key) does not actually correspond to the 8 given buttons. I checked several key values, and noticed that all the unbound keys automatically appear at 0, as well as '~' and esc. Jump is 1, crouch is 2, forward & backward are 6 & 7, look down & look up are 8 & 9, etc. I'm going to start experimenting with KeyState(int key) soon.

[Ishtvan]

It could be that "button" state isn't referring to the _BUTTON* terminology but rather intended for checking mouse buttons, and key state is intended for checking keyboard keys? We set up a system like this ourselves with our own low level hooks, so it's possible this is exposing similar low level hooks that Id used. Just guessing though.

 

The "int" might be directly related to the virtual key code you get with low level hooks, but I still don't know how you get that for a given bind, looking at that header you posted. Make sure you try rebinding your keys to see what happens. I.e., if "jump" is "1", 1 might not correspond to the impulse for jump, but rather the key that you bound to that impulse. Sorry if that's already obvious.

[Nyarlathotep]

It could be that "button" state isn't referring to the _BUTTON* terminology but rather intended for checking mouse buttons, and key state is intended for checking keyboard keys? We set up a system like this ourselves with our own low level hooks, so it's possible this is exposing similar low level hooks that Id used. Just guessing though.

No. ButtonState() strictly checks what Doom 3 uses.

 

The "int" might be directly related to the virtual key code you get with low level hooks, but I still don't know how you get that for a given bind, looking at that header you posted. Make sure you try rebinding your keys to see what happens. I.e., if "jump" is "1", 1 might not correspond to the impulse for jump, but rather the key that you bound to that impulse. Sorry if that's already obvious.

No, sorry. I already checked that. I put jump there for a reason (I edited because I originally had space).

[Nyarlathotep]

I've finally breached the secret of the commands! KeyState() pulls in ASCII characters (range: 9, 13, 27, 32, 39, 44-57, 59, 91-93, 96-122), but only lowercase ones (it gives lowercase values whether or not shift is held down). ButtonState() operates somewhat differently:

 

0: unknown/unassigned button

1: moveup

2: movedown

3: left

4: right

5: forward

6: backward

7: lookup

8: lookdown

9-11: unknown

12-19: button0-7

20: attack

21: run

22: zoom

23: scores

24: mlook

25-88: impulse1-63

 

There is nothing above 88.

 

I'm uploading a copy of the mod I madeto test it. Edit: Is there any reason why I can't upload .rar files? It shouldn't be too hard to figure out. There are two new console commands, keysFromBinding and BindingFromKey--pretty self-explanatory. There are also four new CVars; search for nyar. (key/button)Test is a boolean telling whether or not you want to test KeyState/ButtonState; (key/button)Range is an integer denoting the start of the range that you will see in the top right corner, displayed 16 at a time for your pleasure. I think that should cover everything. Questions? Comments?

[Crispy]

Cool!

 

The forum only allows a few types to be uploaded... it probably doesn't matter much anyway. The important thing is that we know how the function works.

 

Perhaps you could write some detailed documentation on how each function works? (Like you'd expect to see in an API documentation file; parameters, behaviour, return values, and so on.) You could put it on the SDK section of the TDM wiki. You could also copy it to modwiki's SDK coding section so other mods can benefit (good karma ).

[Nyarlathotep]

Maybe later. I've got some projects to pick up on. Then again, I could always wind up being much more free than I expect to be through next Thursday, in which case, absolutely. Is there any particular format I can look at to see what would need to be done for the Wiki?

 

 

 

Edit: for future reference, what types of files can be uploaded?

[Crispy]

If you're not familiar with wikis, this might help: http://www.thirdfilms.com/darkwiki/index.p...c_Wiki_Tutorial

 

As for the format of the page, I'm sure you've seen something like it before. Something like this (example chosen at random from Java docs) - the name of the function, its prototype, a short description, a description of each parameter, and a description of what it can return. (It probably doesn't throw any exceptions - I don't think id used them at all - so you can omit that part.)

 

The forum mostly accepts images for uploading, I believe. Haven't used it much.

[Nyarlathotep]

I can handle Javadocing. It looks like wiki might be a bit easier/faster to do than I previously imagined. I'll try and see if I can't throw a version up tomorrow.