Jump to content

Geep

Member
  • Posts

    682
  • Joined

  • Last visited

  • Days Won

    31

Everything posted by Geep

  1. A trick that might work for you is to use a regular AI, but disassociate the head from the body by using a large distance for the spawnarg offsetHeadModel <x y z>, described in https://wiki.thedarkmod.com/index.php?title=Female_AIs_-_Faces_%26_Heads#More_about_Pairing_a_Head_with_a_Body So, you could have the body in an isolated "basement" room, maybe motionless or doing a path loop, and the head on the floor above, making similar traversals and speaking its lines by any of the normal methods. (If the sound emission turns out to be associated with the body instead of the head, you might need to cut some vents in the floor to allow sound propagation.)
  2. While what HMart says is true, I don't think the performance of objects versus scripts should be top of mind. Use whichever works well for you. If I have a complicated series of actions I need to choreograph, scripting gives me the overview and control I need. Whereas if I do it with objects, I end up with a Jenga of colored blocks whose purposes and dependencies are not obvious at a glance, and so hard to debug. That said, for relatively simple stuff, objects (as you become familiar with them) are easier.
  3. Maybe someone with better modeling skills than me can convert these?
  4. OK, I'll keep it a bit vague. I just like to present a mental model that reflects reality as much as possible. I worry that sometimes the simple models can lead you astray. For instance, the simple model of preprocessor instructions are that they are done in a separate first pass. As far as I can tell from the source code (and I may be misreading this), they are actually parsed and handled mixed in the all the other keyword tokens.
  5. I never saw any model files. I'm guessing creating a model in .ase or .lwo format never happened.
  6. @stgatilov. I'm attempting a draft (not for the first time... it's hard to organize this) of a page specifically about evaluating expressions & variables. Here are two statements you made, about a property with a non-constant expression on the right side: These imply two different things about the value of a property (that is not deactivated): #1 indicates that re-evaluation occurs only when an expression (or an item within it) changes. #2 indicates that re-evaluation occurs at a different time, which might be: (a) about every frame, or (b) whenever any event handler is about to run. (c) whenever an event handler whose body specifically references that property is about to run (There is also the far-less-important question of whether, if the property is set by a constant value or expression, evaluation is ever done more than once. This is just a performance issue that has no effect on program logic.) Your thoughts?
  7. @stgatilov, I want to be clear about the new ";" support in 2.11. The following could cause problems (often quietly) in 2.10. Which ones are now legal in 2.11? Which ones are still illegal but now have warnings? float <user_variable> 0; // has both numeric literal and semicolon <register_property> 0; // has both numeric literal and semicolon <non_register_property> 0; // has both numeric literal and semicolon
  8. I'll mention these as possible TDM 2.12 additional features in the appropriate places.
  9. FYI. Just updated these sections, about syntax for user variable initialization, potentially with non-zero values: https://wiki.thedarkmod.com/index.php?title=GUI_Scripting:_User_Variables#Declared_in_Property_List https://wiki.thedarkmod.com/index.php?title=GUI_Scripting:_Syntax,_Semantics,_&_Usage#User_Variables Also corrected string comparison section in If Statements. And added a mention of property deactivation to: https://wiki.thedarkmod.com/index.php?title=GUI_Scripting:_GUI::_Parameters#Bound_In_a_Property_List
  10. id Studio did a poor job in defining its categorization of variable nomenclature, so in subsequent documentation and discussions there are divergent views (or just slop). In my series, I had to choose something, and went with what I thought would be clearest for the GUI programmer: Properties, which are either Registers (like true variables) Non-registers (like tags) User Variables (also true variables) I see that your view is more along these lines (which perhaps reflects C++ internals?): Flags (like my non-registers) Properties, which are either Built-in (like my registers) Custom (like user Variables) Also, elsewhere, you refer to "registers" as temporaries. I am willing to consider that there could be temporary registers during expression evaluation, but by my interpretation those would be in addition to named property registers. I'm not sure where to go next with this particular aspect, but at least can state it.
  11. Thanks, that's helpful. Regarding (1), I didn't express it quite right. I was actually just asking if that is unchanged from 2.10 to 2.11. I think you are saying, yes, it's unchanged. Regarding (2), yes, you are right. FYI, I will be revising my String Comparisons page tomorrow to make it correct. Regarding (3e), for user variables, let me raise a general point first. Elsewhere we seem to disagree on whether they could be initialized to non-zero values (e.g., using a numeric literal) in 2.10 and earlier. Perhaps it's enough to say that "reliable non-zero initialization" was problematic. Turning to 2.11, do you now feel that your changes have made non-zero initialization reliable? Also, your bugtracker notes mention a change in handling of trailing ";" and also (I think I remember this) some difference between "float" and "definefloat". Could you expand on that? Finally, returning to (3e), I'm thinking syntax would look like this float myAlpha matcolor[3] // with or without trailing ; Regarding (3f), just confirming the correct syntax as: set matcolor[3] 0.5; set matcolor[3] "$gui:alphaFromScript";
  12. @stgatilov: I'm drafting a wiki page summarizing what's new in 2.11, based on your forum and bugtracker posts. I need clarification on these topics (i.e., true or false in 2.11): 1) In expressions, comparisons <=, >=, <, > continue to have the same priority as == and != . This is unlike C. 2) In an event handler body, if(text == "") {/* do this if empty*/} and if(text){/* do this if non-empty */} have always been acceptable forms. What is new is that the first form, which was common, is now deprecated and will give a console warning. 3) Vector indexing is available... a) on the right side of a set command b) on the right side of a transition command c) to initialize properties d) to initialize user variables e) on the left side of a set command for a float f) on the left side of a transition command for a float g) in an if clause 4) In 5869 activities, this is listed: r10012 Now .gui file must contain single windowDef and nothing more. Do you mean a single top-level windowDef? Since it is not unusual to have multiple windowDefs in a GUI. Thanks
  13. Thanks for your further comments. Good to know about that [2.11] public post. I'll be considering the points you've raised, but it probably won't be a fast process.
  14. @stgatilov, you said, RE string comparisons: I'm unclear if you are referring just to changes you made in 2.11. I think equality testing of two strings (one of which is "text") was working and is a good and expected capability, and should be supported. Including against an empty string. I noticed in your bug activities that you did remove some comparisons with ... == "". I see you also removed string concatenation with "\". No problem, but does that mean multiline macros are no longer a thing? (If so, I'll need to change some examples) BTW, the series so far hasn't really tried to cover the 2.11 changes, since I figured it's a work in progress. But since you did a great deal of GUI work in July, perhaps it's stable enough to try to consider it. I see the logs listed in bugtracker, but don't have access to the private forum threads mentioned there: https://forums.thedarkmod.com/index.php?/topic/20526-gui-refactoring/&do=findComment&comment=477179 https://forums.thedarkmod.com/index.php?/topic/21535-order-of-evaluation-in-expressions-materials-and-gui/ (Nor do I have SVN currently set up on my newer machine, for changelogs from there.) Any place else I should look?
  15. This would be a reasonable addition. (However, I would not be in a position to extend it to include subsequent changes from Doom3 made by non-TDM mods.)
  16. I understand what you are saying about the difficulty of testing in the face of crummy code and unusual evaluation behavior. Still, I need to understand this further. Could you post a .gui (or zip a test fm) that demonstrates initialization of a user variable to a non-zero value?
  17. The specific test I did used this GUI, that (in my map testFloatInit, using the March 2.11 beta) was applied to an Entity GUI surface: windowDef test { rect 0, 0, 640, 480 backcolor 0,1,0,1 // green visible 0 notime 0 float vis 1 onTime 0 { } onTime 100 { // set "vis" "$gui::gui_parm1"; if("vis" == 1) { set "visible" "1"; } else { set "visible" "0"; } // resetTime 0; } } Because the resulting surface was not initially green, instead transparent, I concluded that "float vis 1" was initializing to 0. (There was also a script object, used for additional variants, which shouldn't have affected this particular conclusion. I admit that's not the cleanest experimental setup.)
  18. Last month, when I tested, I recall I got the opposite result... it was still 0. So something's screwy.
  19. @HMart, @stgatilov Let's see if the 3 of us (and anyone else with a stake) can agree on the best initialization syntax of User Variables in a property list, which I discuss in 2 places in the wiki. As we know, a float user variable is ALWAYS initialized to zero. Below are possible syntax forms, which I have numbered, and in the comments given my opinion 1a) float myvar 0 // recommended form. 0 is only real value, but needed for proper parsing. Matches syntax style of properties. 1b) float myvar "0" // alternate form 1c) float "myvar" "0" // alternative form (but I hate) 1d) float myvar=0; // DEPRECATED (float crouch_scale=0; from mainmenu_settings_guisize.gui) 2) float myvar; // alternate form with semi-colon, also initialized to 0. 2b) float "myvar"; // alternate form (but I hate) 3) float myvar // BAD. Parser may or may not recover from this, depending on what follows. (I've seen this fail) 3b) float "myvar" // Probably BAD 4a) float myvar 1 // MISLEADING, because variable is still initialized to 0. 4b) float myvar "1" // MISLEADING. 4c) float "myvar" "1" // MISLEADING.
  20. Regarding (1), it clearly was supported at one time, and would seem valuable. Did it cause problems in the past, or was just neglected as unneeded or too tricky when TDM engine merge occurred? Dunno. I'm a fan of this, because it will make GUI debugging easier. HMart is supportive of (2), calling a namedEvent from elsewhere in a GUI. I'm neutral on this. Is someone would like to add these to the bugtracker as feature requests, I'll reference them in the wiki writeups.
  21. Considering your comments, starting with preprocessor directives. More soon.
  22. @HMart, you took issue with me saying: This was my summary of what I thought you meant in these post fragments from a forum linked to by Ref 10 (namely, https://forums.thedarkmod.com/index.php?/topic/20100-idtech-4-gui-scripting/#comment-439778 )... I see I probably shouldn't have added the "[as float parameters]" to the ambiguous "as well" phrase, and perhaps "recommended TDM try" is too strong. Overall, would this be better? "In Ref 10, it is noted that in transition statements, a 4-value color vector must be either a literal or (less reliably) a definevec4. Using a #defined macro for the color vector won't work currently... an idea for a future improvement?" EDIT - I see that a broader revision was needed. So changed to this in https://wiki.thedarkmod.com/index.php?title=GUI_Scripting:_TDM_vs_Doom_3,_Quake_4 ====transition 4-6 parameters==== Often, transition statements have a pair of 4-value color vectors as their 2nd & 3rd parameters. As the discussion in [[GUI Scripting: References & Resources | Ref 10]] indicates, each vector is traditionally represented by a double-quoted literal: transition "matcolor" "1, 1, 1, 0" "1, 1, 1, 0.8" "300" This was id Studio's preferred method, but using a definevec4 user variable was a possible alternative. In addition, TDM can #define colors for transitions. Unfortunately, due to syntax differences, for a particular color, it is not possible to create a single #define that would work with both properties and transitions; thus: #define INACTIVE_COLOR 0,0,0,0.50 #define SINACTIVE_COLOR "0 0 0 0.50" See [[GUI Scripting: Preprocessor Directives]] for further examples. (Possible future improvement: Changing TDM's parsing to let a transition also accept color vectors with commas.) See also the discussion above about 4vect properties and _x, _y, _z, _w suffixes.
  23. Xrays in GUIs added. That and about 4 dozen other pages tagged in category "GUI". My brain is now dead. Time to step away from the screen. @HMart, sorry about that misinterpretation of what you said. I'll revisit and correct that tomorrow. And then start to delve into the many points you and @stgatilov raised.
  24. Got it now. TDM likes to define category templates with an optional pagename parameter, so that if need be a particular page can be placed in a non-default location in the alphabetic listing, e.g., instead of: T This page is about Foo ...it's... F This page is about Foo I'll do likewise.
  25. Yeah, me either. But many of the existing TDM wiki pages seem to use a template, so I'll be looking those and through the mediawiki docs about templates today to fully understand pluses/minuses. Moving cautiously because it's easy to create or edit a mediawiki page (evidently including templates), but almost impossible to delete a page.
×
×
  • Create New...