46
Technical forum / Re:Something about the inventory
« on: August 19, 2003, 07:54:00 AM »
I'm just waiting for the day Jan re-implements 3D entities and makes it possible to do an inventory like that of Grim Fandango. 
- April 26, 2024, 06:40:22 PM
- Welcome, Guest
News:
Forum rules - please read before posting, it can save you a lot of time.
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.
47
General Discussion / Re:Someone, please lend me $85,000
« on: August 19, 2003, 06:16:05 AM »
This definitely would be a very cool vehicle to use in a game. Of course one needn't actually buy it to do so. Research it, model it, negotiate a license to use it in the game -- or just build something like it and save yourself the hassle.
48
Technical forum / Re:Easter Egg ?
« on: August 19, 2003, 05:58:53 AM »
I'll have you know that I wait until I am done using the computer for the evening before I change out of my day clothes -- although a good deal of my forum posting is done well after midnight.
Then again, you're probably not a full-fledged programmer until you know C/C++. I'm learning, but maybe its only a matter of time before I graduate to underwear-posting?
Then again, you're probably not a full-fledged programmer until you know C/C++. I'm learning, but maybe its only a matter of time before I graduate to underwear-posting?
49
Technical forum / Re:Problems with DLL programming...
« on: August 18, 2003, 07:33:41 PM »
This is probably a very stupid question, but -- can I ask what you guys are talking about exactly? Obviously McCoy is trying to write a DLL file containing an external function that reads a file, but I'm not sure I understand what its purpose is. Is he writing something for a future version of WME? Or can DLLs be used within the WME scripting language somehow? Or is this totally not related to WME at all?
50
Feature requests, suggestions / Re:.scale(scalePercent) method for entities
« on: August 18, 2003, 05:15:59 PM »
Personally, I think I'd still prefer Scale Levels for regions, rather than scaling the entity itself.
51
Feature requests, suggestions / Re:Nitpicking from and ex Agast user.
« on: August 10, 2003, 05:27:51 PM »
But how are you going to eliminate that gap? Regardless of how long it is, the gap is always going to be there when you call the PlayMusic function. The only solution I can see is to play and pause the music, and set its position, before you actually need it.
In fact, it might be handy to have a parameter for PlayMusic, in a future version of Wintermute, that tells the music to start Paused..
In fact, it might be handy to have a parameter for PlayMusic, in a future version of Wintermute, that tells the music to start Paused..
52
Feature requests, suggestions / Re:Nitpicking from and ex Agast user.
« on: August 09, 2003, 10:14:12 PM »I'm planning to allow the user to make a connection between those two to reduce the scripting needed for the most common situations.
That would be very handy.
The function must be present in a script it's being called from. If you need to share some functions between multiple scripts, put them into a separate file and use the
#include "path\filename.script"
construct to insert them to another script.
So even though the scripting language is basically object oriented, there's no way to define custom methods for objects? For instance I want to add a few methods to my Actor's script beyond the defaults like "Talk" and "GoTo". One is called "TalkList", which cycles through a given list of dialogue lines each time the "Talk" action is performed. It seems like I ought to be able to add these to my actor.script, thus making them accessible to other scripts by calling:
Code: [Select]
actor.TalkList(self.commentList);
53
Feature requests, suggestions / Re:Nitpicking from and ex Agast user.
« on: August 08, 2003, 09:39:57 AM »
Yeah, that actually clarifies things immensely, I appreciate it. I do still need some help understanding the following, though, if you wouldn't mind:
1) Attaching Scripts - Under precisely what circumstances should I attach a script to an object? If I understand correctly, I should attach a script to an object whenever I want that object to immediately execute a set of instructions, and/or wait for events, independently of any other object or script. Is this correct?
2) Initializing Music - Where in the code should something like music be initialized? Based on WME's intended architecture, is it proper practice to start playing a music file from within the scene_init.script, or is it best to do this somewhere else?
2b) How many music / sound channels does WME support?
3) Items -- The default project contains an "items" folder with a sample book item in it. Is there some way to use these pre-defined items, or do I have to manually place it & reference the image and script from within my scene? Is an item always an entity that must be placed in the "body" of the scene?
4) Function -- I'd like to define some functions so I don't have to re-type as much code, but I'm not sure where to put them exactly. If the function is dealing with interactive objects in the game world, should it go in one of the main game script files? If its only going to be used within one scene, should it be in the scene_init.script?
I apologize if these are stupid questions or not well thought-out, its extremely late and has been a very long day. Also, I know this is probably not the best section to put them in, since it's kind of evolved into a "How Do I Do This" discussion -- but my goal is to understand what Wintermute can and can't do, and how it works in general so that I can stop complaining about it.
1) Attaching Scripts - Under precisely what circumstances should I attach a script to an object? If I understand correctly, I should attach a script to an object whenever I want that object to immediately execute a set of instructions, and/or wait for events, independently of any other object or script. Is this correct?
2) Initializing Music - Where in the code should something like music be initialized? Based on WME's intended architecture, is it proper practice to start playing a music file from within the scene_init.script, or is it best to do this somewhere else?
2b) How many music / sound channels does WME support?
3) Items -- The default project contains an "items" folder with a sample book item in it. Is there some way to use these pre-defined items, or do I have to manually place it & reference the image and script from within my scene? Is an item always an entity that must be placed in the "body" of the scene?
4) Function -- I'd like to define some functions so I don't have to re-type as much code, but I'm not sure where to put them exactly. If the function is dealing with interactive objects in the game world, should it go in one of the main game script files? If its only going to be used within one scene, should it be in the scene_init.script?
I apologize if these are stupid questions or not well thought-out, its extremely late and has been a very long day. Also, I know this is probably not the best section to put them in, since it's kind of evolved into a "How Do I Do This" discussion -- but my goal is to understand what Wintermute can and can't do, and how it works in general so that I can stop complaining about it.
54
Feature requests, suggestions / Re:Region-Specific Scale Levels
« on: August 08, 2003, 09:16:15 AM »
No problemo. Thanks for considering it, when/if it gets implemented it would be a real help -- I'd have to create a LOT of custom-scale regions on those stairs to make the scaling appear smooth!
Thanks for considering it, when/if it gets implemented it would be a real help -- I'd have to create a LOT of custom-scale regions on those stairs to make the scaling appear smooth!
55
Feature requests, suggestions / Re:Nitpicking from and ex Agast user.
« on: August 08, 2003, 05:58:27 AM »
I'll try and clarify my concern somewhat.. as I'm learning the scripting language, I'm finding that I've got to jump between scripts in drastically differing locations to follow the progress of the program. Handling for a left-click is defined in multiple places. As defined in the default scripts, the process for handling a right-click on an object and executing the "Talk" action on the object involves the game.script file, menu.window, menu.script, and then the_object.script, which are located in several different folders. Item-level event handlers have to be defined in individual script files that necessarily are named by the names of the items they refer to. In the default script nearly-identical event handlers are re-defined in every single item script.
None of these are horrible issues, they are simply minor inconveniences that in my personal view make things a bit convoluted. And actually, most if not all of them can be rewritten to fit my taste better.
I thought about it some more, and I think the number one thing that bothers me about this script management method is that the order of the program is all but incomprehensible. After poking around it occurred to me that game.script must be processed before anything else, but I would really appreciate it if the IDE could somehow display the order things are going to be called in.
Other organization possibilities: Perhaps a more parent.child oriented approach, or else a tree-like structure that clearly divides the scripts into hierarchical levels of importance. I don't know -- dunno if I'm even making any sense. At least I know what I'm talking about.
None of these are horrible issues, they are simply minor inconveniences that in my personal view make things a bit convoluted. And actually, most if not all of them can be rewritten to fit my taste better.
I thought about it some more, and I think the number one thing that bothers me about this script management method is that the order of the program is all but incomprehensible. After poking around it occurred to me that game.script must be processed before anything else, but I would really appreciate it if the IDE could somehow display the order things are going to be called in.
Other organization possibilities: Perhaps a more parent.child oriented approach, or else a tree-like structure that clearly divides the scripts into hierarchical levels of importance. I don't know -- dunno if I'm even making any sense. At least I know what I'm talking about.
56
General Discussion / Re:Why is a scripting language a foregon conclusion?
« on: August 08, 2003, 05:31:37 AM »
Well, here's a suggestion -- although I'll admit up front that this idea could detract considerably from the credit given to the author of the engine.
Since WME is free, why not release it alternatively as a well-documented C++ API, for those who would prefer to develop their games the old fashioned way?
Hey, it's just a idea.
Since WME is free, why not release it alternatively as a well-documented C++ API, for those who would prefer to develop their games the old fashioned way?
Hey, it's just a idea.
57
Feature requests, suggestions / Re:Region-Specific Scale Levels
« on: August 08, 2003, 12:50:42 AM »
That's why I put the question in the Wishlist section. What I meant was, isn't there a way it could be considered for implementation in a future version of Wintermute?
What I meant was, isn't there a way it could be considered for implementation in a future version of Wintermute?
58
Scripts, plugins, utilities, goodies / Re:Verb Bar
« on: August 08, 2003, 12:48:46 AM »
Unfortunately, merely attempting to load the project in the Project Manager causes the entire ProjectMan to crash on my WinXP system.
59
Feature requests, suggestions / Region-Specific Scale Levels
« on: August 07, 2003, 05:17:34 PM »
Wintermute lets you have multiple scale levels, and you can specify a static scale level for regions, but I'd like to be able to define scale levels for regions, as well. For instance, in a couple of scenes in our game there are stairs. Stairs go upward, of course, so they take close to double the Y pixels on the screen, but the actor shouldn't be scaled more than normal, if that makes sense. So you've got to have a region for the top of the stairs where the scale levels are based on a flat surface, and a region on the stairs themselves that weakens the scale percentage. Isn't there a way that Scale Levels could be applied to individual regions, instead of/as well as the entire scene?
60
Feature requests, suggestions / Re:Nitpicking from and ex Agast user.
« on: August 07, 2003, 05:09:20 PM »
Morning everyone. I'm Brian, of ForeverDream Studios. You'll surely see myself, Jussi (deadworm), and other members of the ForeverDream Team poking their heads in now and then, since we've decided to make Wintermute our official development tool for our upcoming adventure game, Curves of Danger.
First I want to comment that while I respect Jussi's opinions and complaints, I personally have been very impressed with Wintermute so far. For the most part I'm thrilled with the way its all handled. Its an excellent, free alternative to the not-so-free SLUDGE (I've never done much with AGAST).
My only major gripe is concerning the vast number of individual scripts that are required to build a game -- it can get confusing and sometimes even spaghetti-ish. This is Number 2 on Jussi's list. What I'd really like to see to handle that is a better way of juggling all the scripts than just listing them by folder. Our maybe a debugger would help, since you could use that to follow the actual progression of the compiler through you scripts.
First I want to comment that while I respect Jussi's opinions and complaints, I personally have been very impressed with Wintermute so far. For the most part I'm thrilled with the way its all handled. Its an excellent, free alternative to the not-so-free SLUDGE (I've never done much with AGAST).
My only major gripe is concerning the vast number of individual scripts that are required to build a game -- it can get confusing and sometimes even spaghetti-ish. This is Number 2 on Jussi's list. What I'd really like to see to handle that is a better way of juggling all the scripts than just listing them by folder. Our maybe a debugger would help, since you could use that to follow the actual progression of the compiler through you scripts.