Messages

Rich,have you tried disabling the wireless portion of the router?  Perhaps someone else is accessing the internet through your access point?   Are you able to dump a log from the router to see what's going on?  Maybe you could try to find a free packet sniffer if you are not able to get enough info from the router.   

PS - Sorry for posting in the wrong forum. It seemed like a pretty newbie question to me and I didn't want to upset anyone so I originally put it in the Beginner forum. Hopefully my next post I'll get in the right place.

IMHO, the moderators probably bumped your question to the tech forum so that it would get the attention it deserved.    I don't think anyone is upset because your question started out in the beginner forum.    Probably it's best to start there when in doubt. 

Anyway welcome to AGS, I look forward to future colaborations with you.

Cheers
Rick

[Documentation]

Documentation

I like the overall layout of the IniFile doc which seems very practical and also meets the basic requirements of the international standart on the documentation of that kind, that's nice and I believe each section has its right place.

And what do you think if the "Definitions", "Globals" and "Object-XXX" sections would be put as subsections of a module structure (or whatever it should be named) ...

Yeah, I was thinking the same thing.  I started out with a flat document structure but have since realized there is a need for sub-sections.  I couldn't think of a good name for "Module Structure" either.   For a section name, I was thinking along the lines of the following but couldn't make up my mind:

• Reference
  
• API Reference
  
• Script Reference
  
• Module Reference
  
• API
  
• Scripting or Script
  
  and of course your suggestion
  
  
• Module Structure
  
  So yes I agree with your suggestion about Module Structure, we now just need to pick a name for it, which I guess is of secondary importance. 
  
  

  
  I also think that we should refrain from using the "object" word but use "instance" and "struct" as much as possible to avoid possible confusion.
  

  I know, but I knew to whom I was speaking.  I wanted to make a distinction, for the purposes of this discussion, between structs defined in the header and that have methods from those defined in the script.  I think the former needs to be in the document while the latter does not.   And of course, in the end the document will refer to IniFile rather than Object-1.  Still you make a good point and perhaps we should try  to get in this habit.
  
  

  
  What do you think if a function prototype declaration would precede its description; taking the IniFile function description...
  

  Yeah, that's probably the right way to do it.  I was thinking the same thing and was surprised that I hadn't already done so in the example document.  I guess I thought about this after I did the original document and didn't think about it when I did the most recent update.   I was planning on the document generator doing it this way.  I was even thinking that the HTML version could encclose the declaration in a box and use a different font,color, etc for the declaration.  I was thinking of doing the same or similar thing for all entities in the Module Structure section.
  
  Programming Conventions
  
  

  
  Yeah, programming conventions is an important thing but what I think we should consider in a first place is a module naming and interoperating conventions, since any given module may be regarded as a black box with an internal structure we don't (or do ) care of...
  

  Agree with all ..
  
  

  
  Alternatively, we can allow compilation to proceed and go ahead replace serving module functionality throughout the code. Some kind of warning to report would be nice here though.
  

  Hehe, I asked CJ about this in the beta thread and he said that the compiler
  doesn't support warnings.  So I didn't press any further.  Maybe once we finish our efforts here and have something to show, we can present him with a "list of our demands" . 
  
  

  
  What I mainly wanted to discuss is how we should name our module internally so that that name can be check from within other modules if necessary....
  

  I guess I would reject the following ones; "IniFile:  because of the reason you mention, "IniFIle_" because it looks like an incomplete macro definition and could be easily deleted or inadvertently created. 
  
• IniFile_
  
• IniFile
  
  This one kind of looks ugly, but I am thinking this may be a good thing because it is very easy to notice.  I suppose you rejected  IniFile_MODULE because of the possibility that the module designer would want/need to use that name for something, which I would agree with.
  
• MODULE_IniFile
  
  The only other variation on name is to just use a leading underscore to identify system or required macros (i.e. used for compilation, etc and not for module functionality). 
  
• _IniFile_V100
  
• _IniFile
  
  I like the idea of including version numbers but how would you implement a  "V1.00 or higher" requirement?.    Would we need to include a macro for each major version like this?
  #define  _IniFile 200
  #define  _IniFile_V200
  #define  _IniFile_V100
  
  

  
  As for module (prefix) naming I think mix-cased names are ok, so far we have:
  IniFile.member
  IniFile_MACRO
  IniFile_SomeGlobalFunctionThatWasn'tMadeStaticForSomeReason
  IniFile_enums
  

  What about global variables?
  IniFile_GlobalVariable
  
  What do you mean by "ThatWasn'tMadeStaticForSomeReason"?  Why not just
  global functions.
  IniFile_SomeGlobalFunctionThatWasn'tMadeStaticForSomeReason
  
  Is there a difference between the type name and value definitions? 
  IniFile_enums
  
  Also I am unclear about enum value name collisions.  If two different enum types are defined can they have the same value names.  For example, does the following work?
  

  enum TypeA {
     Paper.
     Scissors,
     Rock
  };
  
  enum TypeB {
     Rock,
     HardPlace
  };

  ===
  Another thing I think we need to discuss regarding programmng conventions is what should be in the header and what should be in the script.  Normally in AGS, most people put all of their macro definitions, etc in the Script Header.  However in the case of a module only those things that are meant to have a global scope should be placed in the Module Header.  That pretty much means that everything in the Module Header should be using the module name prefix as discussed about.     I guess I am stating what is obvious to us and what is implicit in the preceeding discussion but I think this should be clearly stated in any module programmng document we produce. 
  
  This brings us to the next point we haven't discussed yet.  What should the naming rules be for the Module Script?  Here is what I have done so far:
  
  
• IniFile_GlobalVariable
  
• IniFile_GlobalFunction()
  
• IniFile.Property
  
• IniFile.Function()
  
• StaticVariable - Declared outside bounds of any function
  
• ApplicationFunction() - Main function, may call one or more utility function  but not other Application Functions
  
• dynamic_variable - Declared within bounds of a function
  
• utility_function() - Small function, may call other utility functions but not application function.
  
  I am not sure about naming conventions for the following Module Script items.  Should they also use the prefix or should they be forbidden from using it?  I guess my inclination is that they shouldn't use the prefix since it's not necessary.   
  
• structs
  
• #define
  
• enum
  
  Scrop, would you be willing to start a text document describing the above conventions.  I am especially interested in you explaining the compilation and dependancy issues since you seem to have your head around that at the moment.   I don't understand the details, implcations, etc regarding the compilation thing as well as you do.  So I think you could explain this better than I.   I don't mind contributing, perhaps we could take turns adding stuff to the document.  What do you think?
  
  Publishing etc
  

  
  But yeah, I like the idea for the modules author to specify what module can be edited by default and what can't be. But the checkbox can actually be ticked/unticked as one may need.  Revision history thingy would also be neat, I agree.
  

  Then I think we should put them on our "list of demands"

Well, I was too embarassed to ask in the tech forum  , I'm surprised you didn't send me to the old bit bucket.   

Besides, as Proskrito rightly points out, this is a beginners question, so I put it here.  And how did I get the rank of "mighty' anyway?    That's Ok, I find it amusing as well. 

Hehe, about time someone answerd my post!!!  I had to wait a whole 6 minutes, can't you people do any better   

Thanks anyway ,  I appreciate your help Scorp. 

I could have sworn that I've seen an AGS function that returns the number of pixels it takes to display a given string and font, but I'll be darned if I can find it now.  Anyone know the name of this function or WITFN it is?  have any clues how to find it.     Thanks...

You may want to give the Firefox browser a try as well, if you havent already done so... mozilla.org

If I were to start AGS over again, I'd probably not bother with the interaction editor at all but rather have a few more tutorials on object-based scripting. After all, it's not like you can write a serious game using just the Interaction Editor anyway.

Here are some of my thoughts on the subject for whatever they are worth.  First of all the interaction editor is great for beginners because they can get started and not be intimidated by the scripting aspects of AGS.  I believe that is is also true that most experienced folks use it as little as possible.   This and some of the prior comments lead me to think about  some possibilies.   

CJ, if you were to dispense with the interaction editor, as you lament, what form would interaction events take in the script?   I suppose the programmer would enter keywords or predefined function names to identify interaction events.  If this were so, would it not be a possibility to execute interactions defined in  both the script and in the interaction editor?   I guess what I am suggesting is cutting the tight intergration of the interaction editor and the script.  Essentially allow the interaction editor to do what it now does except for the script.  Add to the script language what you alluded to in your comments.   The programmer would have a choice to use the interaction editor or to do script programming (or possibly some combination of the two).

I fully appreciate there are numerous difficulties and that a huge amount of effort would be involved so I am not expecting this to happen in the near future but I am curious about how it might be done (technically speaking) and how people would react.   
=====

Now on a slightly samller scale , when doing "edit script" from the interaction editor, why not open the entire script file and then position the editor window to the interaction function from which the edit was called, instead of restricting the edit to that window?  Would this alleviate some of the difficulties regarding having mulitple edit buffers simultaneously open?   

For me I would be happy to have the header and script opened in seperate tabs whenever I edit a script. 

CJ, Hope I haven't unied your day by asking all these weird questions

Cheers
Rick

Help!! Does anyone have a copy of the AGS source code?

I was keeping it safe in my hotmail account, but then I forgot to access it for 30 days and it got deleted.

Anyone??!?!?!? 

:o  You should have saved this one for April 1

Also, could we have a ModuleRequired or ModulePresent function, that can be used to check for the presence of some other module, after all, there may be dependencies between modules and it would be nice if we could specify this in some formal way... alterntaively a require keyword like Perl...

Thinking about this, I think the easiest solution is Scorpiorus' #error suggestion.

Yeah, I like his idea also.  Perhaps #warn, #info should be included as well, so if one wished the compile could be allowed to complete but a message still generated indicating what happened.   

*** Edit *** removed unreleated quotes

I have been heavily using the module manager and it works great.   I experienced a couple of crashes using beta-15 but haven't seen any with beta-16.   The crashes occured during long AGS Editor sessions when doing " close module script => close module manager => test game".   

Hmm, that's slightly worrying -- I thought the editor issues were fixed in beta 15.

I'll keep my eyes open.  If it happens again I chase it for you..

The only thing that is awakward is going through edit-test iterations.   You have to open the module manager, select the module, edit the module, close the module manager, test the changes.  It would be nice if this could be stream-lined somehow in some future version.   

Yeah, I appreciate this. Some sort of direct access to the module script from the main menu would be handy.

I think it would be ok if there were short-cuts or menu picks to edit the previously edited module script and header. 

[Documentation]

Documentation

As for documentation, everyone has their own idea of what it should look like.
I say keep it simple, just put up a few recommendations of what a proper doc should contain and the file format (TXT or HTML) and let's leave it at that. Anything else is a waste of time IMHO. ...

Anyway, I really like the idea with the document generator to automatize the doc-creation process. Personally, I don't see any disadvantages with such approach as it serves the same purpose as modules themselves, that is for the structurization, which in turn simplifies the management of the whole system. So, it's just a matter of creating the doc generator which is not an easy task I appreciate, and I'm looking forward to finally see it in action. And I would be glad to help with anything I can.

I agree whole heartedly about keeping things simple, because if it's too complicated then it won't get done.  One the other hand a document generator offers numerous advantages but adds a bit of complexity (at least initially) to the process of authoring a module.  It would appear however that the bigest  percieved downside of a document generator seems to be the effort in implementing it.

I propose that we take both Scrop's and Strazer's suggestions.  First we come up with a simple document format that can be easily done manually in txt and html.   Then we make a document generator that can produce same from source code.  In this way if the doc generator is too much for some one to deal with they can just do it manually.  For those who prefer a document generator they can have their preference as well. 

I believe I have gotten through the most difficult part of doing the document generator.   At this point I am not intending to do any kind of in depth code analysis so as to document completely undocumented code as some commercial and/or deluxe document generators do.  The goal is to extract information from resonably documented code and render it into a document.   

I am the point where I can start generating output.  Any inputs about the document format, contents, structure, etc would  be most helpful.  Here is a proposed list of sections I think should be included in the document.  Have I left anything out or included too much?  Which should be main sections and which should be sub-sections?

• Title - module name, author, version, etc. 
  
• Abstract - paragraph briefly describing module's functionality
  
• Contents - table of contents (hyper-linked if html)
  
• Description - description of how to use the module
  
• Definitions - #define constants, enum values, and data types defined in header
  
• Globals - global variables and global functions
  
• Object-1 - properties and functions
    :
  
• Object-n - properties and functions
  
• License
  Here is the current text version of the IniFile documentation.  Feel free to comment or post format modifications. [edit]****updated document below ****[/edit]
  http://www.gaia-spa.com/project/ags/modules/manual.txt
  
  Programming Conventions
  

  
  The programming conventions part is far more important...
  

  Agree, very important.  Perhaps there should be "Script Module Guidelines" or similar document that contains this and other info?   What do you think?  How should we proceed?   
  
  Here is a document I recently produced  describing the conventions I use when writing AGS script language.    Hehe, I was planning on asking you guys to review it, then the new module stuff made it out of date.  Anyway if this is the kind of thing you are thinking about I would be happy to take a shot at doing something similar for modules. 
  http://www.gaia-spa.com/project/ags/doc/ProgrammingConventions_V002.txt
  
  Publishing
  

  
  I for one will put it into the package. It depends on the size of the demo but the default game is so small, a few kilobytes more don't matter to most people. It's up to the module author, really.
  

  Yeah, I can see the advantages of including it.  I guess that's what I would want if I were trying to use someone else's module for the first time.   
  
  

  
  Would be cool if there were an option to only read the code but not edit it. It could still be possible to unlock it by clearing a tick in the module properties. So it's mainly to disable editing by default.
  

  Maybe edit should be disabled automatically when ever a module is imported.  Then as you suggest anyone can enable editing via a check box.   Then if changes are made there would need to be some way of permantly marking the module as changed from the original.  It would be cool if the module manager maintained a permenant revision history.  Perhaps if a module was imported, modified, then exported, the user would be prompted for name, and a 1 sentence summary of changes.  If that copy were then distributed it wouldn't be confused with the original.
  
  

#ifndef MODULE_BLAH
#error Error: Can't find module BLAH!
#endif
One thus can report an error or possibly do other useful stuff like providing an alternative code to replace a module functionality with, etc.

This appeals to me because of the possibility of providing alternatives if a needed module is not found.   What comes to mind is the case where some features of Module-A use some functionality provided by Module-B.  Using this method one could define dummy functions, variables, or whatever to disable the dependent features thus allowing Module-A to compile and it's other features used.   Perhaps there should be several error levels such as: #abort, #error, #warning.   

Also, could we have a ModuleRequired or ModulePresent function, that can be used to check for the presence of some other module, after all, there may be dependencies between modules and it would be nice if we could specify this in some formal way... alterntaively a require keyword like Perl...

If there were a ModulePresent function it would be nice if it could also be used iteratively to get a list of modules.  Some kind of "require" keyword would probably be a better solution though. 

I have been heavily using the module manager and it works great.   I experienced a couple of crashes using beta-15 but haven't seen any with beta-16.   The crashes occured during long AGS Editor sessions when doing " close module script => close module manager => test game".   

The only thing that is awakward is going through edit-test iterations.   You have to open the module manager, select the module, edit the module, close the module manager, test the changes.  It would be nice if this could be stream-lined somehow in some future version.   

I am extremely pleased, great work and thanks ...

Rick

I was just browsing the module script and noticed:
[line 548]: len = secptr-this.nextptr+1;
which AGS treats as "len = secptr-(this.nextptr+1);"
instead of "len = (secptr-this.nextptr)+1;"

Thanks a bunch. I'll look into it and get it fixed. 

Do you feel that it is final and documented enough for general and public consumption? If so, let me know and with your blessing I'll upload it to my resource site.

Rui, you're quite welcome to mirror it. I would say if someone has a need for it they could definitely start using it. As you can see from the original thread most of the issues are related to modules in general. Although, Scorp has identified a few things I overlooked. I think the Get functions need to be enhanced a bit so they can be used to dump a whole section or the whole buffer (i.e. if someone wanted to load a listbox with the contents of a section for example).

I'm either a sucker for consistency or a nitpicker, but I would like to have them capitalized.  ...

I have the same preference as Strazer.   Perhaps it's possible to have both and disallow the lowercase version(s) if "object-based scripting is enforced".   

Is there a teleport character function and maybe a fade in fade out effects function?

You could do something like this:

   FadeOut(1);                          // Fade out effect
   StopMoving(EGO);                //  Teleport character EGO
   character[EGO].x = xpos;
   character[EGO].y = ypos;
   FadeIn(1);                            // Fade in again 

Another thing you may be interested in is the continously loop room in DemoQuest.   If you used something similar you wouldn't need to do the fade in/out, it would seem to continously scroll left  or right. 

I would put "Display" statements in each brach of your if-else structure to see if that behaviour only happens at a particular point.  My guess is there is a flaw in the logic somewhere, but I wouldn't know for sure. 

*** Edit ***
Hmmm, well I guess my first suggestion won't be very helpful since you are using the same NewRoomEx() statement for both possibilities.  I gues the next thing I would wonder about is what code do you have for the "player enters room" events?  Maybe there is something there.  Also is there enough margin between where the player lands and the corresponding edge? 

[Publishing, Licensing]

Publishing, Licensing

In terms of the license, I wouldn't recommend using the GPL. It effectively means that anyone using your module has to make their entire game open-source ...

Yeah, I this was the last thing I added to the document and was just to tired to think about it very deeply.  I started reading through LGPL and just glazed over.  Seems that both of them have a lot of stuff that just doesn't apply. 

Perhaps we should just compose a simple paragraph that clearly states what is expected?  The problem with this, is that it would be uncertain how well such a thing would meet any kind of legal standard.  However, isn't this the case with the AGS license itself?  If so, then I suppose we just do something similar for modules.

Has anyone ever come across the creative ecommons license?  I like their approach, they allow you to select the terms you desire and then they generate a license for you.  You can try it here: http://creativecommons.org/license/

You end up getting something like this: http://creativecommons.org/licenses/by-sa/2.0/

Well, I like to know what everyone thinks about this...

I thought about providing two versions of a module. One that can be modified and the other is a safe one - that can't. ...

I'm not sure this is necessary in light of your next point ...

Also, if an imported module is changed for some reason (because it's allowed or due to an error compiler detected) it would be nice if such module were marked (with an asterix or anything) that it was changed. This is important I think ...

which I also think is very important.   The real problem is that one person modifies a module and then passes it on to another person.  The other person is unaware of the modifications and has problems becsause of them and asks the author for help.  I think a way of permantly marking modules so modified is absolutely necessary.   Shall we make some kind of feature request?

I think we should use zip files, containing the scm file, documentation and optionally a simple demo game.  At these small file sizes the superior compression ratio of rar or ace is insignificant.  Zip files are easiest to access on all platforms.

Yeah, I agree with this.  I wonder if the demo game should be a seperate download though?  The module files are so small in comparison.

Documentation
The concensus seems to be that an external document, combined in a zip package is the desired module delivery format.  The reasoning for this is that an external document can be viewed independently of (simultaneously with) the AGS Editor session.   

The problem I see with manually creating and maintaining an external document is that it will either not get done or not stay up to date.   So I looked into document generator thingies such as the one SSH suggests.   The problem with most of them is that JRE, Perl, Python, or whatever needs to be installed (IMHO not everyone would be willing to do this) and/or that it would take a lot of hacking to get them to work with AGS. 

I have been tinkering around to see how feasible it would be to make an AGS document generator, capable of extracting comments and some statements, such as function definitions, etc, to rendering plain text, html, and sgml documents.  It seems to me not too difficult a problem.  So far I've written parser primatives capable of extracting and intepreting individual lines of text comments in a format similar to the ones in the IniFile module.   Form the expermenting I hav been doing I think it would be possible and feasible to ...

• Generate a document directly from a SCM file.
  
• Generate a document directly from a TXT file.
  
• Interpret natural looking text
  
• Interpret key script statements
  
• Control what is and is not included in the document
  
• Automatically generate table of contents (with hyper-links)
  
• Output document to TXT, HTML, SGML
  
• Perhaps at some point provide capability of documenting an entire game from a text dump.
  
  I wonder what everyone else thinks about this idea?   If there are reasons to take another approach or better alternatives I''d like to discuss them.  If not I'd like to go forward  with my idea. 
  
  

  
  I agree about having an external file with full doc on the module and, perhaps, a brief info in the header itself. I think we should consider a format of an external file.
  

  What do you mean by "format"; file type, document structure, or aestethic appearance? 
  
  File Type - My three file type candidates are Plain TXT, HTML, and DocBook/SGML.   
  
  Document Structure -  I'll prepare an outline roughly based on the IniFile documentation and post a link to it, so that can use this as a starting point for a discussion.  If someone else would like to create an outline then please volunteer.
  
  Aestethic Appearance - I guess we can comment on this as we go through the process.
  
  Programming Conventions
  

  
  Having a module name prefix is definitely worth it. A think maybe general purpose functions could be made static and thus grouped together.
  By the way, should 'defines' be like: INIFILE_BUFSIZE or IniFile_BUFSIZE ...
  

  I think the module name should be unique in a case insensitive manner so that upper-case, lower-case, and mixed-case versions of the module name can be used as prefixes.  I used "#define INIFILE_BUFSIZE..." because #defines are normally in all caps.  On the other hand the alternative "#define IniFile_BUFSIZE" appeals to my sense of simplicity/consistency (i.e. don't need as many prefixing rules).  I wonder what the others think? 
  
  

  
  Yes, a prefix should definitely be used. I also think adding a (maybe abbreviated) prefix to function names would help grouping related functions for the auto-complete feature.
  

  I am not sure exactly what you mean by abbreviated prefix?   Do you mean an abbreviation of the module name or additional abbreviations, such as "DelSection(), DelOption(), DelValue()" to control the list order in the auto complete.   I think abbreviating the module name increases the possibility of name collisions.
  
  Announcing, Reviewing, Release Module List
  

  
  You might want to look at the LGPL (Library GPL) which is based on the GPL but designed for add-on libraries.
  

  I guess this is probably the one to recommend.  Any other ideas???
  
  

  
  I think they should be announced and debugged in the Technical Forum, then moved to the Technical Archives just as Tools and Plugins are now.
  

  Sounds like a plan.  Any other opinions, ideas?
  
  Thanks for your inputs.  Let me know what you think about an AGS document generator. 
  
  Cheers

being able to open other scripts read-only while editing a script? I'm often needing to quickly check something in the header, for example...

I would even go so far as to suggest that whenever a script is opened for edit the corresponding (i.e. in the case of a module script) header file also be opened for write. 

Hehe, I hope you didn't think I was implying that you were those things.  Slackers usually don't make it through engineering or computer science so I assumed you were not.  My comment was, as you surmized,  just a pathetic attempt at humor.   

Hang in there and I'm sure something will come your way.