Menu

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.

Show posts Menu

Messages - Docmovieman

#1
Thanks for this! Just got back from a holiday trip and it was nice to find a present here under the tree. :)

I've done a bit more exploration since I started this discussion and, despite my frustration that I give things names but can't access those things via those names at runtime, I think I've managed to get a handle on how I need to work it all out. Your module will definitely save me a lot of coding time since I can pass along a lot of variables without needing to write to files. Then it's just a matter of a "translation table" so that I can tell the game "object[0]" in Game 01 is equal to "object[10]" in game 02.

Cheers and happy holidays!
#2
Yup. Yup. I'm a little bit frustrated (with myself, not the software, mind you). As I planned out the rather complex game, I assumed that if I gave something a name, I could put that name into a variable and call it using said variable. Since I was locked into the AGS numbering/indexing system, I spent a lot of time coming up with a very good naming system.

It just seems that if I give it a name, I should be able to address things by that name.

After thinking on it some, I guess the best workaround is to just iterate through everything. I've got a variable called CHRCurrentOutfit
  • that has the "Name" (not the Script-O name, but the informal name - like "Plain Ratty Overalls". So, now if I have 10 characteres in the game, I run X from 1 to 10 and on each loop, I scan every inventory object in the game until I hit upon something that matches "Plain Ratty Overalls". If it does, I can exit the loop and set the variable CHRCurrentOutfitID
  • to that object number...  Though I haven't looked yet to be sure that I can do this with VIEWS or not.... :(   This, essentially, doubles the amount of variables I need and creates thousands and thousands (10 characters, 100 objects is a thousand iterations per  - and then I have to do it for 2 more views, each character's object inventory, and whatnot) of extra "Game Load" processes.

    Then again, I may just need to rethink the whole thing.

    Thanks to everyone for the tips, insight and suggestions. They are very highly appreciated!



#3
Sigh. I'm realizing now that the stuff that I thought was possible before with inventory items and characters won't work, either. So, I'm going to have to rethink the whole game.

Basically, various characters have different outfits, hairstyles, hats, and other accessories that they change throughout the game.

So, if Bob is wearing his sunglasses, his speaking view might be "BOBSSUNGLASSES". When he then starts Chapter 2, I want him wearking the same clothes for his normal view (BOBSOVERALLS) and headgear for his speaking and thinking views (BOBSSUNGLASSES).

If in Chapter 1, those sunglasses happen to be view number 25, then I have to make 24 empty views (and I dare not use any of the earlier views unless I'm certain that that view won't come into play during the course of this chapter).

In the above way, I would save the game and write a file with the first line being 25 (the view of his glasses) and the second line being 26 (or whatever view number his outfit is).

What I would LIKE to be able to do is to write the NAME of the view to the file and have it load the proper view (or inventory item or whatever). This way, I can keep my naming conventions consistent, rather than keeping the ViewID index numbers consistent. I'm limited to the number of views I can use in a game, but I can give those limited number of views any name that I want - thus, if I don't use "BOBSOVERALLS" in game number 2, it doesn't matter. But if I have to go by numbers, I ALWAYS have to reserve View 26 to be Bob's overalls, whether he will be wearing them during the course of that chapter or not.

Basically, since I'm limited to quantities, consistent numbering conventions are useless for multiple games. I need consistent naming conventions that I can associate those names with any number in any game. <shrug>

But, since this doesn't work with even inventory items or character names as I'd originally thought, this is more of a project than I had originally thought. Soooooo.... I guess I'll have to come up with some other sort of workaround on my end.

Oh well. Thanks.
#4
Quote from: strazer on Thu 07/12/2006 17:25:46
BOBSOVERALLS is replaced with the number of the view at compile-time, so no, you can't use the view name from a variable.

Right.

But, if this Tracker'd Item is implemented, then it should work for both plugins and within the basic scripts, right? If that's not the case, then is there a way I can request that I can be able to access views by their names?
#5
That's been my point all along, Rui - I need to be able to access views by their names - and those names need to be variables since - well, they vary.

And, upon further testing, even the old "character[1].ChangeView(Variable)" doesn't work either. It NEEDS to be the actual NAME, not a variable containtaining the value of that name.

So, once again, I'd like to add my vote to boost the priority of this - be it for plugins or accessing it from within the normal game scripts...





#6
Hmmmm. Doesn't seem to work for me.

in this, CHRSpeakView (sub x) is a string set to "BOBSPEAKING" and I get an error on the following line...

Code: ags
character[x].SpeechView = CHRSpeakView[x];


"Cannot convert string to int"

The following line causes the same error:
Code: ags
character[x].ThinkView = String.Format("%s",CHRThinkView[x]);


I've simply got to be being a complete idiot, here - I'm just being so stupid that I can't spot where my idiocy lies. :)


#7
Thanks Strazer...

I didn't spot that before as I was trying to change "SpeechView" in my testing (since I saved that first in my file). So, if I'm correct, I'm limited at only being able to change the character's main view by name, right?

This is definitely good news anyway and am thankful for the tip. At least this way, I can load the "Speaking View" by name as the character's main view. Then I can change the character's actual speech view by accessing the view index number from that main view. It's a bunch of extra code, but at least it's possible now. Thanks so much for the help.

#8
In my game, I'm creating it in "Chapters" with each chapter being a different AGSGame executable. Some characters and items and their current states carry over from game to game while others are unecessary for the next chapter. Therefore, I'm using "names" for characters and items. This way, when I load up character "BOB" he doesn't need to always be "character[3]" in every game. If I was forced to store these by the index number, it would get very convoluted down the road since that character ID (3) is useless in any game chapter that Bob isn't in. By addressing characters (and inventory items) by their unique names, I can reuse unused character and item indexes for new things.

Views need to be worked the same way. In chapter one and chapter three, Bob might have a pair of overalls to wear and the view for that might be called "BOBSOVERALLS". If I have to reserve VIEW1 as "BOBSOVERALLS" in chapter 2 (so I can have it back in chapter 3) then, again, I'm wasting resources.

There's no real way for me to make my game without being able to access everything in the game by either name or index. As far as I have seen, everything else besides views works this way.
#9

One more question (for you or anyone else who wanders in here...) are GlobalStrings carried over as well as GlobalInts?

Doc
#10
Great. Thanks for that! I was afraid it was only the "Global Ints" that carried over, but being able to get back to a previous state when switching back from a different game would surely be helpful - then I only need to track the variables that change rather than EVERYTHING in the game.

Thanks again and I'll check out your module tomorrow when I get back to coding.

Doc
#11
Hiya Everyone...

I've been searching and searching and have also not been able to find a specific answer to this question in the documentation. So, I'm hoping that someone can give me some insight and save me a few days of complicated testing and experimenting to figure it all out.

BACKGROUND

I'm working on a fairly complicated game that will have a series of "Episodes" or "Missions" that will be released over a period of time. There will be one "BASE GAME" (Game.exe) that controls everything, and then each "Mission" will have it's own Mission000.exe. Since I would like to have the events of one mission affect another, I need to carry over a lot of variables.

My problem is that I'm not exactly sure just WHAT carries over when I run the game. The documentation doesn't seem to include some of the changes made in the "Game Variables" thread. And the docs also have the cryptic "and so forth" which doesn't really explain what is shared all that well.

THE SITUATION

I've got, for example, 5 characters with a Trait called "Resistance".  It's in an array as CHRResistance[X] where X is the ID of that character. I've made a Module for this that has all of these array variables available throughout the game. This module is included in each of the mission games, as well as the base game.

So now, in Mission 1, Character 2 gets their resistance lowered to 20 (from the original 50). If I now run "Mission2.exe, 1, 0" (The 1 keeps the "GlobalInt" values according to the docs) - will the CHRResistance[2] variable be 20? or would it not be initialized at all and be "null" - or exactly what would happen?

If it doesn't carry over, then I suppose it's possible to dump all my arrays into a file and then read that file in the new mission game - but it seems like a lot of work and makes it difficult to adapt and add to the concept as things go on.

I have some other workaround ideas, but they vary depending upon the answers I get here, so I will hold off on them until I get a response - and then we can look deeper, if necessary.

Thanks in advance for any help you may be able to offer.

Doc

SMF spam blocked by CleanTalk