Messages

I don't think replacing this

"(Formerly known as MoveObject, which is now obsolete)"

with this

"(Formerly known as MoveObject (object,  x, y, speed), which is now obsolete)"

would bulk up the manual very much.   I know it would be a bit of work to go back and add the information and that it may or may not be worth the effort.   I'll leave that determination to CJ or whomever. Cheers.

Feedback on Porting Old Code to New -

So far it's pretty painless.  The one thing that comes to mind though is the lack of the old function prototypes.  The "(Formerly known as MoveObject, which is now obsolete)" type info would be much more helpful if it included the parameter list.  I know that generally they are the same as the new function but not in all cases (I think).   Having the former parameter list available would inspire confidence in the  porting process, IMHO.   Just my two cents worth. 

Well if you put it in a script module and made accessor functions then it would be easy for anyone to pick this up and use it.   Struct within a struct isn't supported because (my understanding) of pointer management and garbage collection issues.   Although defining one struct in the header and the other in the global script appear to work at the moment it is not guranteed that it will work in a future version nor is it guranteed to not cause problems in the current version. 

You of course may do whatever you want.  I understood you to be asking for alternative methods for what you are trying to do so I took the time to explain how I would approach such a problem.  If you find my approach useful then feel free to  use it. 

There are two ways I can think of.  In both cases you need a big char buffer.

char buf[6000];  // 200x30

The first mnethod is to store strings in the buf using a null terminator (i.e. buf=0;).  Then to access the array you would simply walk through the buf and count the number of nulls until the count is equal to the index of the string you wish to access.  This method makes the best use of memory space but perhaps gets a bit hairy if you plan on doing a lot of insertion and/or deltion of array elelments. 

In the second method you woiuld just allocate a fixed number of bytes to each array element.  For example lets use 200 bytes for each element.  In this case array element 3 would start at buf[600] and end at buf[799].

1.  First make a copy of the file backup_editor.dat (to editor.sav for example)

2.  Open the global script editor from the menu "Script->Edit Global Script"

3.  Search for "interface_click("

4.  If you don't find then scroll down the script looking for any fragments of that funtion you may recognize.

5.  If that doesn't work then exit from AGSEDIT and copy the saved backup_editor.dat file (i.e. editor.sav) to editor.dat.  Open AGSEDIT again and start over.   

I am using this patch without any different behaviour. 

The problem I have using test is that ocassionaly when the game begins the pallette appears to get screwed and the screen colors are all weird.  This happens in the first room after a short delay (5-10 seconds).  It's possible the problem happens when I initiate some event such as a mouse click or movement but I can't be sure.   Making a room transition (even to the same room) clears up the problem and it never happens again in that specific test session.  The problem does not occur every time, fairly infrequemntly actually. 

I haven't reported this before because I knew there were outstanding issues regarding test and that they were not successfully reproduced.   In light of the patch it now seems apporpiate to document what I am seeing and hence this report.

Monkey, I have to agree with Strazer that the best thing to do is to implement this as a module and use accessor functions to do all the work.   It looks to me like the puppose of dlgUnit is to implement a string array.  You could just as easily implement a string array using  a single char array (much larger of course) in the dlgStruct structure.  Just my two cents worth.  Hope it's helpful.

I came across this and thought some of the muscian folk may be interested (if they don;'t already know).  It also looks like a good place to find game music.  I haven't looked very deep yet.   Perhaps someone with a stronger interest and more time can take a look and let the rest of us know what's up (or down) with Opsound.

http://opsound.org/opsound.html

OK, I just tried Prefinal 3 and it seems to have cured my problem.  I'll let you know tomorrow after I do  mor testing.  Thanks.

rich,

Try going back to RC3 version to see if that works.  I am having the same problem, and most recently the crash occured when opening a game and then immediately editing the Global Script.   I went back to RC3 and everything worked just fine.  Also save your editor.dat and backup_*.* files in another directory for safe keeping.  You may be able to recover some of your work. 

Hmm -- I just downloaded the pre-final and the zip file you posted, and I'm able to open it, edit room scripts and then the script header and global script without problems. Has it happened again since you rebooted? Rather strange.

It's was happening to me all the time until I went back to RC3.   I seemd to me that RC3 was able to open one that caused PreFinal to crash.   I'll give it a go again when I get  a chance.  I guess it could be because of the crappy WinME OS I am using.

Also I have noticed that the editor will allow 30 hotspots to be defined but a mask containing more than 16 colors can't be imported.    Is this a bug or a limitation of the mask import mechanism?

Well, there's a manual, why didn't you check it out first?

Extracted from description of RunAGSGame():

The save game slots are shared between the two games, and if you load a save slot that was saved in the other game, it will automatically be loaded.

But since RunAGSGame() wasn't used that much (and I won't use it anyway), I'm not sure if it's really working (well the last game I played using this feature was RR4, which seemed to work okay, that game had lotsa crashes though. )

[quote autor=Pumaman]
Nothing has changed, if the size of the global script data segment changes, you cannot load a saved game. That means if you add or remove global variables from the script you should find that old save games will no longer load.

When I read the manual it wasn't at all clear what actually happens.   The behaviour most of us have observed and  CJ's explanation seem to be at odds with what the manual says about two or more different games sharing the same save slot(s).   The situation is still not clear and some clarification would be gretly apprreciated.  Thanks.

Yeah, I'm wondering about this too, regarding the RunAGSGame() feature.  What happens when you load a save slot that was saved from the other game?   

I'm getting an editor crash if I edit a room script, exit/save, and then try to edit the script header.  It seems to be repeatable for me at this point.  I haven't rebooted windows and tried again yet, if that fixes it I'll be back and update this post. 

*** Edit ***
After further investigation it appears that the game files are corrupted.   Attempting to edit either Global Script or Script Header, without doing anything else casuse a crash.   I restored the main game files from a backup I made a couple of days ago and now everything seems to be working.   The game that causes the crash can be found at the link below, if that is of any interest.   

http://www.gaia-spa.com/project/demo/Archive/DQSOD-T00.00-005.zip

I am able to open the editor.dat file with metapad and see my files in there.  I suppose I can just cut and paste to recover.  Any advice or cautions would be appreciated.  Thanks..

*** Edit ***
The cut and paste thing seems to work, so everything's back.  The game is still up there if it's of any use. 

*** Edit ***
Well, after editing one of the room scripts a few times I come to find that the editor.dat file is again corrupted, or at least the editor crashes when editing the global script or header.   I can recover everything again but I don't think I'll be able to make much more progress until we figure out what's going on here.   

*** Edit ***
I have reverted back to the RC3 version and haven't had a problem since.   I also did a cleanup of my machine (scan disk, defrag, spybot, regclean, etc), other than a couple scan disk errors  from a power button reset a while back there were no anomolies found.   

I believe that RC3 version was able to read the same editor.dat file that nade the PreFinal version crash.  When I reverted to RC3 I expected that I would need to restore my Global Script and Script Header by cutting and pasting as I describe above, but to my surprise they opened without crashing.  I suppose that I may have done the recovery and forgot about it but I don't believe so.

1.) Shouldn't #defines, static variables and utility functions in the module script also be prefixed with the module name as not to collide with anything the game author may have set up in the global script header?

I don't believe the Global Script Header is included into Module Script, only the Module Header. 

Btw, I like "Internal functions" better than "Utility functions".

I suppose there could be a whole discussion about both terms "Utility" and "Application" to possibly come up with better names.   I choose to apply "Utility" to the functions that do all the dirty work and "Application" to the functions that provide a clean interface to some high level functionality.   In my mind "Internal" seems to apply equally to both. 

Does anyone else have opinions about this?

2.) If only a specific function depends on another module, we should suggest to use
  #ifndef YourModule_VERSION
    AbortGame("Can't find required module 'YourModule'!");
  #endif

The #ifndef, #endif, #error,  ect.. are directives that are only executed at compile time.   AbortGame() is a function called at runtime.  The #error directive does more or less the samething as AbortGame() but at compile time instead of at runtime.   Having said that, a variation of your idea would make it possible to use only one macro definition to manage dependancies. 

You would check for the existence of the module in the Module Header as Scorp suggested.  If YourModule is not imported into AGS prior to MyModue being imported into AGS then an error is generate by the compiler.  So far this is what is currently suggested. 

Now to check the version of YourModule, this could be done at runtime, as you suggest Strazer, instead of doing it at compile time as Scrop suggests.  The advantage of doing it at runtime is that only one macro will be required;  there is always a possibility of someone deleting those additional version macros from some future version of the module and breaking other modules.   The disadvantage is, ofcourse, that the error won't be detected until runtime.   Here is an example of what I am talking about.

// YourModule Module Header
#define YourModule_VERSION 200 

// MyModule Module Header
#ifndef YourModule_VERSION
#error *** Error-MyModule, can't find required module 'YourModule'!
#endif

// MyModule Module Script
function start_game() {

   // Check module dependancies
   if (YourModule_VERSION<150) {
      AbortGame("*** Error-MyModule, version YourModule V1.50 or greater required");
   }
}

Any comments about this ?  SCROP, SSH, etc...

copiler errprs

Hehe!    I find that one funny.   ALso, why do we call them "compiler errors" when in fact it was the programmer who made the error and not the compiler?  Perhaps from now on they should be refered to a s"programmer errors"?   

In any case thanks for checking my spelling.  I'll get right on it and correct those "author errors".

==================

Also, I would like to add you guys to the credits of this document as it is just a summary of our discussion here.  So if you would like me to do so please PM me your  frist, last, and forum name so that I can add it to the document.   

Cheers

I think it's an interesting idea.  The 200 characeter string length shouldn't be a problem unless you wanted to have lines longer than that.  Take input from a textbox, one line at a time and dump it to a listbox.   Go for it!!

SSH,

Here is a first draft of a document that drescribes what I believe was the concensus of the discussion in this thread.  If something needs to be changed or added please let me know.

• ModuleProgrammingGuidlines
  
• ModuleScriptTemplate
  
• ModuleHeaderTemplate

here are a few fairly obvious ideas you have already thought of, but just in case you haven't:

1.  Make sure you close the recording session (arrrrrgh! terminology).   There should be a setting somewhere in the CD Burner Software (Nero in your case) that allows you to add more files to the CD at a later date or to "close" the CD.  Try choosing the later option and close the CD or recording session or whatever terminoloy Neo uses.

2.  I've made MP3 CDs as you describe.  MP3s in the root directory and also in sub-directories.  The MP3 players I have tried them on allow you to navigate the directory structure if you have on. 

3.  I've used the "Data CD" type of formating which it sounds like you have also done.

4.  Have you tried playing your MP3 CD's in a DVD or other MP3 players?   Perhaps the player you have is not what it advertises or is defective.   

This is then turning line 49 into:
player.Walk(object[0].-24000, object[0].Y, eBlock);

That makes sense.  I knew it was something on my end but couldn't think of anything. I wasn't aware of the "#define x" since I hadn't personally coded it. Thanks for the help.

*** Edit *** Arrrrrgh! I did, I did code it after all!!!!  It was a template for setting up #define terms....   

SSH, thanks for bumping the thread.  Yeah, I think we reached a concensus of opinions.  Scrop said he would write up something about the "#define Version" stuff.  I plan on writing up something on naming conventions etc.   I have had to take a temporary break from this to  get DemoQuest in shape for the new AGS releasel.   Do you have an immediate need or is this more of a general inquiry?  If there is anything I can help you with please just let me know. 

Cheers