HeroEngine Forums
Welcome, Guest. Please login or Register for HeroCloud Account.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - HE-JAY

Pages: 1 ... 5 6 [7] 8 9
Hooking onto the area load, player login or player travel sequences requires a decent amount of background knowledge about how the engine works.  If you're just getting started, I'd recommend you read some introductory material first in order to get acclimated. I'll include a list of relevant wiki articles at the end of this post.

Hooking into the area load process on the client requires performing the following steps:
  • Glomming a custom, game-specific version of the 'base client' class onto the $BASECLIENT system node (the example we provide is E_BaseClient).
  • Extending the _AreaLoad method by implementing the method HE_AreaLoad in your glommed 'base client' class.
  • Adding the desired function or method calls to the body of HE_AreaLoad.

Note that this will only execute HSL on the client.  If you want to execute code on the server, you'll need to perform similar steps for $AREA._OnAreaLoad.

Suffice it to say, this is a relatively involved process that requires knowledge of:

I would also read the following in order to get used to the way HSL and HeroEngine works:

After you've read this material, I'd be more than happy to help you tackle more complex logic like this in greater detail.


There are certainly tools available to create clumps of assets which you can then import into other areas in order to give the illusion that the player is in a subset of the parent area, but the kind of functionality you're suggesting implies that we want to programmatically (and on-the-fly) chop up and recombine areas to generate instances whose geometry (and potentially other data) differs from the 'parent' instance in some small (or large) way. In practice, this would be highly inefficient, as we'd have to generate new area .dat files, stream them to the user, programmatically alter geometry and other data such that the area acquires the attributes that it needs in order to function properly in the new instance... etc.

You do have several options available, however (and I'm sure there are others beyond the ones I'll list):
  • You can duplicate some of the 'parent' area's geometry (tools do exist in-engine to create asset groups that can be added to the asset library and imported into a new area), then add this to a new area which you can instance.
  • You can instance the entire common area and allow many groups of players to undertake missions (using our CoH example) in different regions of the city/area. Each player or group of players might exist in their own spatial awareness system, and each would be oblivious to the fact that there are others running around outside in the same area 'just out of sight'
  • You can implement (similar to the above option) a type of 'phasing' (as it tends to be called these days) where players in a particular segment of the storyline are shifted to another awareness system and their movement or actions are influenced/restricted to fit their new environment. Using this method, you could dynamically replace the open gate with a closed gate and enforce restricted movement while introducing mobs and other entities to the player.

In short - the precise functionality you're describing is not present, but there are simple ways to create the same net result.

Scripts stored locally in the HeroScriptCache directory are plain-text and not HSL bytecode. Only after being transmitted by the editor to the server does a script get processed, compiled, inserted into the repository and version-controlled. Copying files in the repository does not - in itself - trigger any action by other systems; thus - even though it is true that script and guixml data is stored in specific locations in the repository, one should not assume that this is a valid interface to the system.

In general, direct manual manipulation of script and guixml data is highly discouraged.  If you can tell me what you're trying to accomplish and why you feel you can't meet those requirements using the build-in tools, perhaps I can help you find a way to do so.

Scripting & Programming / Re: Noob script question
« on: Jun 27, 11, 03:18:59 PM »
As Luke suggests, there are a couple of ways to communicate between client and server:

For remote calls, you can communicate information back and forth by making calls that follow the format:
Code: [Select]
From Client:
  call server someNode.someMethod(...)
  call server someScript:someFunction(...)

and then, from the server:
  call reply someNode.someMethod(...)
  call server someScript:someFunction(...)

For replication, you can set a field (for example, a custom 'gamePlayerClickTarget' field) to replicate to the client that will update automatically when it changes on the server; you can then respond to this change or simply access the field at some future point. The replication tutorial (http://wiki.heroengine.com/wiki/Replication_Tutorial) is a good place to start in order to learn how to set things up properly. Using bare-bones remote calls, however, will be easier to implement and might be a good method to use for an initial attempt.

Also, you are correct in stating that both 'untrusted' and 'remote' methods and functions may not return values. Instead, you'll need to use 'reply' remote calls or replication to achieve multi-step communication.

Let me know if you have any additional questions.

Animation / Re: Animated Assets
« on: Jun 23, 11, 01:33:57 PM »
Animated assets will use the physics representation of the asset's static pose; they will not update their physics representations (either client-side or server-side) to match arbitrary changes internal to the object. In order to view the physics representation of an object, you can use the Physics Panel and turn on "Visualize Physics Data". After setting the Visualization Distance appropriately, you should see your animated asset's geometry highlight. If you don't, then it is possible the physics data has not yet been built for the object. To test whether this is so, find the Test Build Asset button in the Physics Panel and activate it. If the physics representation was not visible before, it should now be.

You can read about this on the 'Collision representations" wiki page:

As far as interacting with the asset, you can toggle various flags on an instantiated model (see the "Collision" group in the Properties panel for the model) to allow/prevent collisions with the player, with the camera, with NPCs, etc.

As Josh suggests, one way you can accomplish this is to use the $TRAVEL system to trigger a move for your player from one area instance to another. Then, as your player enters the area (in HE_PreEnteredArea), you can move them to the appropriate destination location.

This process will likely require you to transmit additional information over with your player; you can do this on the account node itself, or you could send a message to the destination area ahead of time saying "expect player X; he is traveling to gate Y", at which point your destination code can re-route the player to the appropriate location when he arrives.

GUI Creation / Re: How to use GUIGraph?
« on: Jun 10, 11, 09:27:25 AM »
Now I canīt find anything about this type "GraphStyle", it doesnīt seem to exist.
Checking the DOM Editor's "client enum" section and searching for 'GraphStyle' will reveal information about the type. Specifically, you'll see that this enum has three values defined: LINE, AREA and BAR.

Other question - am I right that minRange and maxRange mean the minimum and maximum value that any coordinate of any vector in the needed Vector3-list has?
The minRange and maxRange values will determine the 'view' onto the data that you are presented with. In other words, the visualization of the data will present a graph of the data points where the lower-bound visualized (the lowest 'mark' on the axis) is minRange and the upper-bound is maxRange.

Also, does the "useRange" argument work at all?
If you set useRange to false, you will be presented with a view encompassing all data points regardless of their value (effectively overriding your range definitions)

Now that I believeto have the arguments right, I still donīt really know how to implement a GUIGraph...
QuestSummaryGUI and QuestStats in HJREF provide an example use case for using GUIGraph controls. If you model your code after these examples, you should have success. _window is not a GUIGraph control and thus would not be the correct choice for your createNodeFromPrototype call; 'graph' would be a better choice.

If you still have issues after following the examples provided in HJRef, feel free to continue asking questions.


Design & World Building / Re: Maximum extent of an area?
« on: Jun 09, 11, 09:18:31 AM »
jcsmith's suggestion is probably the best under the circumstances. The current editing tools are very geometry-centric in that editing offsets and making connections is done with the geometry as a reference point. With no geometry, editing the area offset would need to be done via script. This is simple enough to accomplish and could be automated to create reference objects at the origin and then link areas to one-another with a predefined offset.

Design & World Building / Re: Maximum extent of an area?
« on: Jun 08, 11, 04:19:50 PM »
As Cooper notes, the illusion of vast, open spaces is often far more effective (and efficient) then explicitly mapping out thousand-kilometer swaths of space.  I can understand the desire to satisfy personal curiosity about the limits of an engine in order to better understand what it can do and how it operates, but the more appropriate question to ask is "What exactly am I trying to achieve, and how can I get there as convincingly and inexpensively as possible?"  Many games employ tricks designed to convey the illusion of vastness: modifying movement speed relative to perceived distance, or using fast travel (warp, for example) to visually transition between two bridged areas.  In the end, your choice of implementation will be guided not by some arbitrary upper limit, but by an intelligent assessment of what you can expect to accomplish with the resources available.

As to your other questions:
  • The default character controller uses physics to sweep the area directly under the player to determine whether the character is currently located above collide-able geometry each frame.  If this test fails, the controller interprets this as a 'collision' and refuses to allow the character to move any further.  This behavior is completely customizable and there is no constraint on the character (whether it be a biped, a ship or an amoeba) as far as position or orientation goes.
  • Currently, seamless travel is not set up to handle three-dimensional seamlessness automatically. While it's true that seamlessly connected areas may have arbitrary spatial correlations (they can be on top of, next to, or within another spatial area), triggering the transition is currently done 'under the hood' and is related to physics. There are ways to get around this, but true three-dimensional seamless transitions aren't currently supported 'out-of-the-box without any additional tweaking on your part.'
  • Characters most certainly can and do interact across seamless 2.0 boundaries. The HSL code must take advantage of language features designed to work with seamless 2.0 (such as proxylocal and proxyforward methods), but this is fully supported.  Hero's Journey (and to a lesser extent the mock fantasy template that is delivered to HeroCloud customers) - while an excellent reference to get the general feel for how to implement certain features - should not be considered an authoritative source for optimal design or implementation. In the case of Hero's Journey, all of that code was created before seamless 2.0 was even added and will thus not showcase these features.
  • Camera control is completely customizable and may be restricted, modified, sliced, diced and whipped to your taste. With some manipulation, you can create many useful illusions regarding rate of travel and creating soft barriers, and you can indeed create triggers that will respond to their presence or absence.


Scripting & Programming / Re: Skills question...
« on: May 31, 11, 10:00:11 AM »
Updating Immutable-ish Data
You are correct to be wary of modifying the DOM in a production environment (as this is very much not recommended).

There are two ways you might handle this situation:
  • Update the DOM during a planned maintenance outage and keep the max skill level immutable
  • Make the max skill level mutable and store it either in the skill spec or a separate oracle which you could reference from your skills

If you choose the first option, you can safely ignore the ambiguous nature of the max skill level and - if it changes - just perform a scheduled maintenance outage (making sure you take into account any consequent effects of raising the skill level).

If you choose the second option, this becomes slightly more dynamic and could handle changes to the maximum skill level while the world is running.

Instantiating Spec-derived Objects
If indeed there is a significant amount of mutable data involved in your skills, I do agree that instantiating spec-derived objects is the way to go. If, on the other hand, all you need to keep track of are skill levels - it may be more appropriate simply to keep a data structure mapping skill id to skill level (as an example). This is kinder on the programmer to code and less of a resource hog than creating objects for each skill simply to track its level.

Skill Notifications
Two comments on this point:
  • Using ChatArea is almost certainly wrong, as that will message every player in the area. If you must use the chat system to deliver messages, use ChatPlayer.
  • Better yet would be a specific call in your (theoretical) $SKILLS system node, perhaps $SKILLS.notifyPlayerOfSkillEvent(...), which would then call the client-side $SKILLS node, which would then notify any listening GUIs, etc. Far better to use your system nodes as public interfaces than to rely on the chat system or something similar.

Let me know if there are any other questions you have regarding specs, spec oracles, etc.


Scripting & Programming / Re: TextInputGUI
« on: May 26, 11, 09:59:37 AM »
I assume you're talking about the _textInputBox gui control; if not, stop me now! (:

Gui controls have - for the most part - two basic components: the visualization/structure, and the underlying hsl code (functionality).

The visualization/structure is defined by the guixml for the control (which is generated from the GUI editor when you create or edit a control); this structure can contain a complex hierarchy of GUIControls. For example, the _textInputBox control has four children which define the borders of the control (top, bottom, left and right). These are simple _panel controls and just have their background set to the color black (no texture is used). If you want to redefine the look of a clean-engine control, it's recommended that you derive a new control from it (by creating a new control in the GUI Editor) and naming it something unique (for example, M_textInputBox). If you want it to handle input events in a unique manner, you would also want to create a new class, implement the new event handlers inside of it, and base your new GUI control off of that class.

Instructions on how to do this is located at:

If you have any additional questions, don't hesitate to post here. I'm glad to offer assistance.


Scripting & Programming / Re: Spec Oracle problems
« on: May 18, 11, 01:37:24 PM »
That error implies that the spec oracle you are requesting to load is named simply "SpecOracle".  Since this is a remote call from the client, my best guess is that you've neglected to make the proper modifications to the client-side scripts in HE_SpecOracleUtils and your spec oracle's classmethods script.

I would recommend going over the steps in the tutorial once more, paying close attention to each step in the process.  Make sure the classes inherit properly from their respective base classes, make sure your prototypes exists, make sure you've added clauses in your HE_SpecOracleUtils to fetch the appropriate prototype, and make sure you've properly overridden the methods in your oracle's classmethod script.


Scripting & Programming / Re: levitate and rotate
« on: May 17, 11, 10:33:31 AM »
What exactly are you trying to accomplish?

If your goal is to make a one-time adjustment to the position and rotation of an object (for example, opening a door, rotating a player-constructed workbench, etc), then it's best to perform this rotation on the server via script (modifying the position and rotation fields on the instance directly).

If your goal is primarily to create a visual effect (for example, a floating eyeball that weaves and bobs and rotates), you could use prop bucket instances on the client and modify their positions/rotations from script (or parent them to a pathfollower, or a combination of both).

Finally, if your goal is to allow a character to levitate, you will need to modify the behavior character controller script to support this.


Hello there Jarryd,

Scott and Josh have given some very good advice for new HeroEngine developers.  As Scott had mentioned, that error indicates that you've implemented a method (your signature might resemble "method someMothodName(...)") in a non-"ClassMethods" script.  The resolution for this is to either change your method to a "function someFunctionName(...)" and invoke it via ScriptName:someFunctionName(...) or to create a class definition via the DOM Editor and open the associated ClassMethods script (there is an "Open Script" link in the DOM editor when a class is selected). Then, place your method code in this script.

The tutorials linked by Scott and Josh are excellent resources and should provide a great start.  If you have any additional issues, don't hesitate to post here. We are - as you have discovered - a helpful bunch. (:


As Scott mentioned (thanks, Scott!), the method HJ uses to highlight characters and other objects is to modify the AmbientColor and DiffuseColor properties of your HBNode in response to a mouse event.

This entails the following:
  • Create a mouse input handler in a class that exists on your character node (usually done through glomming onto the HBNode on the client)
  • Make sure the node's MouseTargetable property is set to True and the MouseTransparency property is set to False.
  • In response to the Enter/Leave mouse events, modify the ambient and diffuse color of the character via the AmbientColor and DiffuseColor properties. This can be as simple as manually setting the values in response to each event, or as complex as creating (as Scott mentioned) a pulsing effect and remembering the old values between states.

A very basic example of such functionality in a class glommed onto your node might be:
Code: [Select]
shared function InputMouseEvent(args references Class _MouseEvent)
  targetNode as NodeRef of Class HBNode = args.MouseTarget
  if targetNode <> None
    when args.MouseEventType
      is Enter
        targetNode["DiffuseColor"] = "#3.0,2.0,2.0,1.0"
        targetNode["AmbientColor"] = "#3.0,2.0,2.0,1.0"
      is Leave
        targetNode["DiffuseColor"] = "#1.0,1.0,1.0,1.0"
        targetNode["AmbientColor"] = "#1.0,1.0,1.0,1.0"

Pages: 1 ... 5 6 [7] 8 9