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 - JMurdick

Pages: [1] 2 3 4
1
Very sad, yes.  380 people out of work.  However, they fell into the same trap that Cheyenne Mountain did.  BigWorld themselves told Cheyenne that Unreal was not a good renderer to try and tie into their server architecture, but Cheyenne went ahead and tried to do it anyway.  And failed.  38 Studios tried to do the same thing and also failed.

Course, look at their "walkthrough" video on YouTube.  They spent a TON of money on art.  Wow.

2
A really good place to locate functions is right here:  http://wiki.heroengine.com/wiki

There are a couple other good places:

1) _ExternalFunctions script.  This is present on both Server and Client (and different on each).

2) Search for "utils" in the HeroScript Editor on both Client and Server.  Be sure and check "Show Engine".  You'll find quite a few that have useful functions, such as ListUtils, DebugUtils, and ObserverUtilities.

3
Scripting & Programming / Re: Spec within a spec
« on: Apr 21, 12, 05:59:04 AM »
If there's a possibility that your equip locations might need additional data (like you described with item rarity) in the future then probably doing them as a spec would be the better way.

A spec would only need maintain a reference to another spec in the form of its ID.  In the Spec Editor you'd provide a window or a dropdown list from which you could select from a list of specs.  In the past I've used a remote call when building the GUI to populate the list.

4
Could always go with a system that is simply a list of item names with a small icon to the left.  And then let the player sort by various properties (name, type, value, etc).  No slots required there, no worrying about organization and saving it out.

5
In the wiki example the class itself could store the data since its instantiated with whatever data you need.   And therefore the timer which is a part of the class (node) can retrieve that data.

6
If you look at this wiki page:  http://wiki.heroengine.com/wiki/Timer

Notice that the name of the function being called is the <timer_name>_tick().  Looking at your code examples makes me wonder if the timer in ApplyTimeHeal is being treated as a local variable and thus does not have scope beyond that function (hence, the other script cannot be called).  I'd recommend doing it the way you see in the wiki, place a timer onto the Effect class and instantiate that class and when its instantiated thats when you setup the timer and callback.

7
Scripting & Programming / Re: Converting Float to Integer
« on: Feb 27, 12, 01:22:48 PM »
Ah, my bad.  I didn't notice that the arrow was one-way there. 

8
Scripting & Programming / Re: Converting Float to Integer
« on: Feb 27, 12, 09:06:48 AM »
HSL automatically converts data types when you assign them to a value of a different type.

http://hewiki.heroengine.com/wiki/Auto_converting_data_types

9
Game Dev and Gaming / Re: Writers do more than quest-writing.
« on: Feb 16, 12, 06:34:11 AM »
As mentioned above, there are lots of places where those with writing skills can contribute on traditional MMOs or even single-player games.  Beyond quests, you have dialogue, item descriptions, help and tutorial text, cut-scenes, and I'm sure I'm missing some.

Plus, it helps to write the background of the world in order to get names of items, places, and npcs consistent.

10
Scripting & Programming / Re: Quest System Design
« on: Feb 10, 12, 04:27:44 AM »
Definitely a good start!  For quests that require you to kill or gather something you might consider a list of IDs/Quantities.  That way you could say "Kill 4 of those and 8 of these".

You'll probably also want a Requirements package somewhere.  Such as "You must be level 20 to get this quest" or "You must have a reputation of 1000 with Bob" or some other such thing.

Oh and don't forget the all important "TalkToQuest" where you simply are asked to go speak to someone else.

One final thing that could make it even more complicated is your list of monsters to kill, items to gather, etc.  You might consider making it a list of IDs so that if you had more than one type of Wolf, for example, it could count towards the kill total.

11
Scripting & Programming / Re: From area id to noderef
« on: Feb 06, 12, 12:17:42 PM »
Seems to me if you are going to have Area weather a System Area would handle this way better than each Area handling it individually.  That way the System Area could coordinate between Areas and allow you to have some semblance of consistency between Areas.  i.e. if its raining in Plains Area 1, its probably also raining in the adjacent Plains Area 2.

12
Scripting & Programming / Re: Associating data with an area
« on: Feb 03, 12, 07:13:21 AM »
Another way is to glom a class onto the area when it is spun up and that class contains the data you need.  Or has an association with the data if you need it to be persisted.

13
Scripting & Programming / Re: Region Name pop up
« on: Jan 25, 12, 01:02:03 PM »
I believe this is in place in HJRef if you wanted to look there.

14
Quote
A lookup table to determine the min max and default values of a specific attribute based on the selected race of the character.

I would suggest putting these values into the Race Spec since you never know when the person(s) doing content design may want or need to alter the values either for testing or later on down the road when a new race is added that (for example) they decide they want to be super strong from the start.

15
Scripting & Programming / Re: Member fields implementation
« on: Jan 24, 12, 11:45:57 AM »
Fields defined in a class are inherited.  So, if StatSystem contains Strength (int) and Dexterity (int) then so will Character.  And Character can call methods that are in the inherited class' script.

Pages: [1] 2 3 4