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 [2] 3 4 ... 9
This maintenance has been completed and the server has been returned to service.

Cluster 20 is currently undergoing emergency maintenance.  We hope to have the cluster returned to service soon, and updates will be posted here as they become available.

Scripting & Programming / Re: $EDIT - how to do it
« on: May 11, 12, 10:55:54 AM »
To get the current room (on the client, of course):
  • Know that the method $BASECLIENT._Room_Activate is called from c++ every time it is detected that you should be in a different room than the one you were previously in
  • Know that _Room_Activate then calls $BASECLIENT._SetRoomName, which will store the name of the current room in the field _roomName(
  • Know that you can use this room name when making $EDIT requests back up to the server

This work has been completed.

This work has now begun.

Scripting & Programming / Re: Character Appearance
« on: May 03, 12, 12:56:45 PM »
Take a look at the client-side _characterAppearanceClassMethods script to see how the default clean engine implementation handles attempts to change the current character specification.

In short (how it's most often used):
  • The field _characterSpecification is changed on the server by you
  • The change replicates to the client and is handled in _onReplicationFieldChanged (in _characterAppearanceClassMethods)
  • The character specification is loaded.
  • A call is made to the external function RecreateCharacter which unloads the current visible HBNode and recreates it with the new character specification
  • Now you have your new character node

Scripting & Programming / Re: Animation speed fknob?
« on: May 03, 12, 12:50:21 PM »
That is correct (: All agents in the animation system have a float knob named "Speed", and this knob is interpreted under the hood as a 'speed factor' for animation playback.

In general, character controller state is communicate from a controlling client to the server and then replicated to observing clients; those observing clients then interpret the state change by changing animation inputs on their client-side version of your character to play the correct animations.

The process is basically:
  • Look at the class _ACCCClientControl, which is glommed onto a client-controlled character on the server and then replicated down with the controller to the controlling client
  • Note that this class has several fields which are marked to reverse-replicate
  • Look at the client and server-side scripts for _ACCCClientControl and note the replication callbacks; look at what they do
  • Duplicate this behavior in your own controller or extend the functionality of the client control glom to suit your needs

To understand what the "hold" command is doing, you'll have to look at the script for the character controller attached to your character; by default, this will be HeroEngine_ACCControllerClassMethods -- look at the doBehave method and find the "hold" section (you'll also see sections for other commands such as 'anim' and 'input' -- these are all defined in script and can be extended as needed).

Scripting & Programming / Re: Animation speed fknob?
« on: May 03, 12, 10:43:20 AM »
Code: [Select]

A more in-depth example can be found in the FPS Demo world (specifically, the FPS_ACCControllerClassMethods script); note that you need to take into account the fact that this will increase the speed of 'all' animations on the character, so this is more appropriate for an overall haste effect than a speed change to a single composite animation.

Scripting & Programming / Re: e_statusBar question
« on: Apr 13, 12, 10:05:24 AM »
Typically, new GUI controls should inherit from a GUI prototype and class that provides the minimum required base functionality needed.  In the case of e_StatusBar (which only needs to respond to event messages and update its display), inheriting from _panel works just fine.  This status bar control - as implemented in the E_StatusBarClassMethods script - simply registers itself as a listener to an external object (in this case a node of class E_playerAccount or E_playerCharacter) and responds to calls to $LightweightEvents.raiseLightweightEvent (which calls lightweightEventRaised on the GUIControl) by updating its internal displays. This sequence of events starts in E_playerAccountClassMethods on approximately line 40 and on E_playerCharacterClassMethods at approximately line 18.

Here are some resources to assist in understanding the GUI system and the Observer pattern:

In order to set the Render property on a character, a few things must be true:
  • The character must have been replicated down to the client
  • The character must have been promoted to an HBNode

The sequence of events is basically:
  • Account and character are replicated as part of the account's replication group
  • Callbacks are made in (by default) _playerAccountClassMethods to respond to the replication of the account and character
  • _makeCharacter is called on the _characterAppeareance for the character, which in turn calls CreateCharacterWithID
  • If successful, the character is now an HBNode and may have the Render property set (you can see an example of this in action inside the _makeCharacter method at approximately line 57)

Overriding the last step in this process and setting Render to be false should prevent your character from rendering by default.

Maintenance on these worlds has now been completed.  Access has been restored.

That's correct.  There's a method on $_PROPS called _PropsSpecOracleGetSpecDecoratorClasses that - if overridden - will allow you to add decorators to the list.  Similarly, _PropsSpecOracleGetValidBaseClasses will allow you to specify additional base classes for your spec (in the rare case that you want to use a spec class not derived from _PropSpec).

These worlds will be inaccessible while maintenance is being performed.  We will update this thread with more information when it becomes available.

There are several ways of accomplishing what you're trying to do.  I'd recommend taking a look at the Prop System (http://hewiki.heroengine.com/wiki/Prop_System) to get a feel for how to replicate nodes that will act as an interface between the user and the actual control panel.

In short:
  • Create a server-side class which inherits from Prop that contains a field which will point to an asset instance in the area's geometry (your 'control panel'); also include a field to specify the GUI prototype you wish to display when the user interacts with the control panel.
  • Create a class derived from PropSpec which will instantiate your custom Prop class.
  • When the Prop replicates down to the client, respond to this replication by glomming your control class (a class that will handle input and displaying a GUI) to the node specified in the Prop instance
  • Make your control class respond to mouse clicks by showing the GUI on the client.
  • ???
  • Profit.

An example of a Prop which exhibits this kind of behavior is _FadingVisibleProp.

Note that you can also implement the concepts used in the Prop system independently in your own code (e.g. the concept of storing data meant for the client on a field belonging to a server-side node; replicating nodes to the client and responding to the replication callback; etc)

Pages: 1 [2] 3 4 ... 9