Messages

Chris, I noticed you still included v1.1 of my verbcoin template.

I'm updating it to v1.4 this weekend (minor bugfix and further code cleanup compared to v1.3), so you can include that version in the next release candidate. (or AGS 3.0 final)

Ah yes, thanks for that. Is your latest version based off the modified version of 1.1 that was included with AGS, ie. having the new template icon?

Yup, v1.4 is available now. There should be no errors whatsoever anymore in it. I'll probably write some documentation you can include in the help file soon.

Thanks 
Anyway, could you also specify what the error was, since i already heavily modified your script to fit into my game, so i'd prefer resolving it myself (actually i know which line of script causes the error, but i didn't understand what's its function, so i didn't remove it)

Yes, the error was a few old lines of code that weren't supposed to be there. You've already found them (was easy enough), and they can be removed without any problems.

was removed:

Code: ags

else{
    ProcessClick(mouse.x, mouse.y, eModeLookat);
    clicked=0; 
    timer=0;
}

in the

Code: ags

if (Mouse.IsButtonDown(eMouseLeft) == 0){

section

Chris, I noticed you still included v1.1 of my verbcoin template.

I'm updating it to v1.4 this weekend (minor bugfix and further code cleanup compared to v1.3), so you can include that version in the next release candidate. (or AGS 3.0 final)

Wouldn't want people to be bothered by the bugs that existed in v1.1

[on the XML subject:]

on the XML subject:

So the idea is to have an standard description of rooms and characters, like what already exists in game.agf, but with all the remaining binary information in it too, so some rewritten engine could load this data easily. And this other engine implements the entire AGS script engine, and AGS API?

No. That's not quite what I meant. Let me clarify:

AGS (so Chris) writes a simple xml game exporter, which puts all the game resources in a pre-defined xml schematic (he is provided with an xsd, XML Schema Definition)

all the game scripts are put in this xml "as-is", so basically copy-paste into the proper node. a node marks the script as being AGS-type script.

Now, that's as far as Chris would have to go. No further work required.

...on his behalf, that is; The ScummVM community, using their own (custom) engine, takes the exported xml, and compiles it in their own game language.

To get all the specific AGS script functions across, the ScummVM community uses the AGS help file as a reference to build their "converter" API, which converts the AGS scripts to their native game engine language.

Now, this means the ScummVM team's got a lot of work to do implementing such a thing, but like I said, if they take a look at SLAGE and have a chat with it's developers it might not be all THAT much work.

Using the help file's description of what each function does will help them a lot, and I think it would be a hell of a lot easier when you know what it does then to try and partly reverse engineer old game engines. So I'm sure the ScummVM team is upto the task, if they're willing.

To summarize:

- adventure game engine developers would only have to build a light-weight xml exporter and provide proper documentation of their script functions

- the ScummVM team would have their own run-time engine which takes the exported xml and through the use of a converter API they write using provided documentation, they compile the exported xml.

- this allows the ScummVM team to decide for themselves which functions to support or not (for AGS I suggest only bothering with the new object-oriented functions and leave out the legacy code, but that's something they'd have to discuss.)

on the proprietary - open source subject:

whilest many of the community wouldn't mind if others "ransacked" their games to build new ones, AGS also has hard working commercial projects;

It is unfair and unacceptable to allow people to "rip" stuff from commercial games to use in other (possibly also commercial) games.

Sure, we don't mind if it's, say LucasArts or some big giant company, but what about those small independent developers, who worked really hard to produce this absolute gem of a game with all new sorts of crazy fun stuff? Would you deny them their livelyhood? They can't afford to go after every crazy fan with a bunch of high-priced lawyers, you know. And they are more likely then not the target commercial developers who will actually use AGS. (Big companies tend to use their own proprietary game engine, anyways.)

And although you might mean well, and say this won't affect their livelyhood, it will. Even worse, it will make every just-starting-out commercial developer make a big wide pass around the AGS engine. (which can't be what we want)

I suggest you read up on the subject, if you're interested; I know I did.

So, anyways, this is why AGS needs to have a proprietary format.

Now if the above makes you think I'm against open source, rest assured, I am not. I however do believe that one must balance open source and closed source, as both CAN co-exist peacefully together. (that's what the whole GPLv2 is all about)

It's a mistake to think everything has to be open source. I know you can have parts open source and parts closed source working harmoniously together.

...right, let me just rush along and go to the summary before I got off on an even longer talking spree. (did somebody say, "too late?")

To summarize:

- IF you want to make AGS open source, only make it open source in part. Leave a closed source part, a "special" compile option, if you will, with a proprietary game format. Commercial developers will use it, amateur developers do whatever they want with it.

- if you go with this, only the open source variant could be used by ScummVM and have cross-compatibility

- I believe for AGS, it is better to stay on the current course and go with the XML exporter if the ScummVM team decides to work on an universal game engine thing

Anyways, I hope this has all been somewhat enlightening (and that I don't get a whole bunch of angry amateur developers on my back who disagree with me for sentimental reasons, not knowing the facts, like always tends to happen if you mention "you can't steal someone's stuff or break their copyright". Seriously, the commercial AGS developers aren't the big companies. They need to be left alone legally. Give them a break.)

(legal disclaimer: Oh, and this doesn't mean I condone stealing/breaking copyright from big companies either.)

That's all well and good for defining inventory items, characters, etc ... but what about the game scripts? Chances are that this "universal language" would have a different set of script commands to existing systems like AGS, and probably a different scripting language as well; converting that all over would be a mammoth task and probably impossible in several places.

ah, but here's the genius, you DON'T convert scripts. You just pass them over. An API then handles the script. (all other stuff should be easy enough to export)

so you would get something like: (oversimplified)

<game="A great adventure">
    <character/>
    <room/>
    <room>
         <object/>
         <hotspot/>
         <script>
              <script-type="AGS">
              <content> Character.Say("Something smart"); </content>
    </room>
</game>

As scotch says, it's pretty much an impossible task.

a bit difficult, yes, but impossible, no;

It mainly depends on the way the "universal" XML game language is built, and on how much functionality is put in the API.

Note: The conversion would have to happen in the editor (no converting a compiled game), so it'll be the game developer's responsibility to choose whether to convert it or not and if he/she's using extra plug-ins, module code and what not, the conversion might not even be possible.

The developer would still have to check after the conversion if everything still worked as intended.

The only open source bit for the game engine developer to write here is the game script API, of which the most obvious functionality could be written by others (who get the information of what does what from the AGS help file, their own experience and just plain asking you, Chris)

Well, the number of people argument doesn't really work here because there are of course a smaller number of people making games than playing them. And if releasing the AGS source code meant that people stopped using AGS to make games because they didn't want people to be able to easily rip the resources, then you end up with an open source game interpreter with no games for it.

Of course a determined person will be able to rip anything they like, but as we've said before it's all a matter of effort. As long as it's reasonably difficult, it should stop random kids ripping a room and some characters and making unauthorized sequels/parodies/etc.

This may not sound like a major issue, but actually it is. I remember last time we had a discussion about this, there was an almost unanimous feeling that AGS games should not be decompilable; and that if the code was open source then people would be likely to move away from using AGS.

You've got to remember that ScummVM is largely used to run classic games from the good old days, which is a different kettle of fish to running brand new games like those made with AGS.

In that regard, you could have a "proprietary" game format which is compiled/stored differently then the regular "open-source" format. (I recommend keeping the current format as "proprietary", so all games to date remain closed, and you'll get no complaints from commercial AGS game developers)


Anyways, I'm NOT advocating you should spend a lot of time on this, Chris, in fact, I'm saying you shouldn't.

While many would want ScummVM to be able to run all AGS games to date, I don't think that's an achievable goal, or even a desired one.

AGS runs just fine on windows, and if you want to play an old DOS version, use a DOS emulator or something;

The ONLY reason why you should even consider allowing SOME games to run under ScummVM, games where their own developer chooses to do so, is it's cross-portability.

[Handle inventory clicks in script]

I found a bug in your template: when the inventory is on screen, clicking on a point where there's no object, with a character, an object or an hotspot behind the inventory in that place, results in looking at it... i tried to make the inventory gui clickable (the background), but it didn't worked...

So if I understand correctly, you're clicking on an empty patch of the inventory and the "look at" action is executed if there's something behind it.

This occurs if you didn't have the general option "Handle inventory clicks in script" set to true.

Please check on the general settings tab under inventory if "Handle inventory clicks in script" is set to "True". If it isn't, please change it. (If it is already, let me know, and I'll double-check my code.)

EDIT: ah, after checking I agree it IS a bug. I must have made a mistake with the latest code updates, as this shouldn't occur. Expect a fix later this week.

edit: another bug (at least i think it's a bug), the player character doesn't walk (yes, i made the walkable area)

Characters walking or not has nothing to do with my template code. It has everything to do with views and the latest engine updates. (Try adding a bunch of frames to the first 4 views.)

This is a game engine issue, and is mentioned (I believe) in the AGS 3.0 RC1 thread.

I wonder has anybody ever considered defining an intermediate XMLish game language?  Game development systems, such as AGS, could export to this language and runtime engines such as yours could either run intermediate language directly or have a compiler that converts the intermediate language to a native form? 

Actually, this seems like a reasonable option. Let's consider:

- SCUMMVM defines a universal XML game language (In which case I urge them to take a good hard look at the SLAGE engine, which allows developers to make games in pure XML, and is pure open source. (java) Downside of the SLAGE engine is it's still in development and a lot of work before their game editor hit beta stage. However, the actual engine pretty much works, according to the developers.)

(so if those friendly folks at SCUMMVM would be willing to spend some time helping out their development team, I'm sure they can get a win-win situation there.)

...ehum, anyways, while they are off doing that, Chris does what he does best, that is improve the AGS engine, bring tons of new dazzling features, solve bugs, and make AGS better then ever 

With me so far? Ok, now when this universal XML game language (slage-based or not) is developed by SCUMMVM, they can (nicely, of course) ask the developers of game engines (such as AGS) if they would be so kind to create an export function which exported their game to this new universal XML game language.

So at that point in time, Chris can still decide to build such an exporter or not.

The result:

- SCUMMVM can offer a universal XML game language (open source) to game engine developers and offer their multi-platform and other benefits as a "selling" point, so they build an export function

- AGS keeps getting better without being bothered with this stuff for a while (seriously, I like cross-platform, but I REALLY, REALLY like the new features and bugfixing a whole-of-a-lot more.), and keeps it's options open.


...so anyhoo, just my 2 cents.

Since I was busy with it anyways... here's version 1.3 (download link in first post of this thread)

It adds double-click functionality to all hotspots/objects which have the 'act' property set to true.

Just thought you guys might find that useful... The double-click speed is completely configurable, of course.

Code example given (try a single and a double click on the Advanced 3D Room hotspot)

Template updated to v1.2

All outstanding issues have been adressed. Enjoy!

See http://www.adventuregamestudio.co.uk/yabb/index.php?topic=32745 for the latest template. (for AGS 3.0, though if you import the module code in AGS 2.72 it should work too)

after adding more character animation frames (there were a few missing), the bug doesn't seem to occur anymore. I think it might have something to do with animations.

How do you mean? Were there whole loops missing, or did you just randomly add a couple of walking frames?

I had an empty loop and others with only one frame.

Well, really this type of error should never happen. If it does, it's useful to report it here so that I can investigate what might have caused it.

However, if an old version of AGS is involved, then there's not a lot that I can do with the information, really.

see my post here: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=31519.msg427453#msg427453

similar bug, latest version (ags 3.0 beta 15)

I got this weird crash when clicking near the edge of the screen:



I've just imported a walkbehind mask and moved the room's edges, though I dunno if that's relevant.

EDIT: the bug appears when clicking randomly.

after adding more character animation frames (there were a few missing), the bug doesn't seem to occur anymore. I think it might have something to do with animations.

That's a really cool Template, solid work!

Thanks.

You should be able to fix the resolution issue by removing the check for room 1.
It shouldn't matter if the code is called in every room.

Was planning on it.

A small suggestion: you're using many, many GetAtScreenXYs, especially in rep_ex.
Instead, you can put

Code: ags

Object*o=Object.GetAtScreenXY(mouse.x, mouse.y);
Hotspot*h=Hotspot.Get...
Character*c=...
InventoryItem*i=...

at the start of the function and use o, h, c, i afterwards. Will save a lot of typing and even a short deal of CPU time.

Hmm... I'll look into it.

I've noticed a bug: open the VerbCoin over anything, then move the mouse ENE, above the talk button. The coin will disappear although the cursor hasn't left it.

No, that's no bug. It's the custombutton1 which is sitting above the talk button. A little left-over from my personal game gui which has 4 buttons.

Just set all custombutton1 layout values to 1 to fix this, like I said above. Since there's no action defined for custombutton1, you leave the gui when moving over it.

Another thing I've noticed:
You're using checks for Hotspot.GetAtScreenXY(mouse.x, mouse.y) != null.
Those checks will never fail because it doesn't return null but hotspot[0].
It's a mean trap, and I fell for it a couple of times myself

Hmm... not sure of this one. I added all the checks because otherwise the game would crash constantly with null pointer errors. I'll check it out.


I'll update the template when I get around to it (maybe this weekend), right now my game project is the main priority again.

[major issue:]

Nice work with the graphics Misj, and with the template update Electroshokker! It's looking really good!

Thanks! Just noticed beta 15.

I discovered some new issues in my template whilest experimenting around a little:

major issue:

- high resolutions (800x600 and all higher resolutions achieved through filters) aren't supported yet. The verbcoin blinks in the upper left corner rather then open properly. This is a coördinate positioning bug.

minor issue:

- I left the custom_button1 expanded, so it can interfere when moving over the verbcoin to the right. Just setting all layout values to 1 fixes this.

I'll fix these issues and update the template.

EDIT:

- the high resolutions problem is not an issue. It only occurs if you call a room other then 1 from on_game_start()

- as for the custom_button1: see above fix.

Do that will ya?

Version 1.1 is released. It includes basic keyboard support and all new graphics (and some minor jokes)

(Only thing "missing" is the label gui not displaying which custom action you're doing when pressing one of the action keys, like when using the mouse)


Notice: for some reason I couldn't save it as a template anymore (AGS just crashes when I try that), so I deleted the big files (debug and the backup sprite set), and zipped it all.

@Chris: could you figure out why it crashes when attempting to save as a template?

Nooooo! - Not dodgy home-made images

Alternatively, I would like to give a small gift containing alternative (png) images for an AGS-template-Verb-Coin.

Great! I'm pretty much done fixing the code to more user-friendliness as well as some bug fixes. I created a background containing some stuff from the old AGS demo game and quickly threw in an old colored sketch for character.

Only thing left to do now is add keyboard support... then I can release the new template.

The module could have a function that sets up keyboard shortcuts. I think that would be the best way to make things configurable in the global script and avoid people editing the module but keep the internals of the module hidden:

SCUMM_VERBCOIN_GUI.SetShortcut('X', eModeWhatever);

Sounds good to me. One thing's been bugging me for keyboard support, however: there are custom text properties in which you can fill in the action being performed for display when moving over a button. (so when moving over the mouth icon, for example, you could have "Drink from bottle", "Bite hamburger", "Chew gum", ...)

If I set keyboard shortcuts to immediately perform the corresponding action, you don't get to see the custom text. I'm thinking about popping up the verbcoin when you press a certain button and as long as you are holding the button down the corresponding verbcoin button will look "pressed" as well as the corresponding text showing in the label gui.

Does this sound workable, or would it be annoying? Perhaps I should include an option which enables/disables this type of keyboard reaction? (so if set to "enabled" you would see the verbcoin and the custom text when pressing a button, if set to "disabled" the action would just run)

Or maybe if you press a certain key only the custom text label would pop up for as long as you press down the key? (and not the verbcoin)

What do you think the best way would be to implement keyboard support? (I want the one using the template to have total freedom)

Also, I have to ask why the functions are so verbose and use numbers rather than GUI pointers

Basically, I spent more time thinking what functionality and options I should give your average AGS developer rather then the way to present it.

So thank you for your suggestions! I'll incorporate it in the next release. (Probably date of release: this friday or saturday)

Actually, you'll find that if the template is well designed, people rarely change standard keyboard shortcuts. And if you provide for Look, Talk to and Use and leave placeholders for the other three modes, people will find their ways to them quite soon. I support Radiant's suggestion for having shortcuts in the template itself.

Yes, but I was talking about the module code. I fully intend to add keyboard support the way you suggest, but I'll add it in the template globalscript, where it's easy to find and customize.

If people start murking around in the module code (which does all the heavy lifting for the verbcoin gui) who knows what would happen.

I've been testing my own template further to fix up all the loose ends. I'll be posting an updated template later this week.

known issues:

- creating one of the 3 custom buttons will cause the game to crash when moving over them. This is due to a text property not being transferred to a string variable. (to be fixed)
- no keyboard support (to be added)
- still uses the old SetText() function (minor issue)

AGS 3.0 beta 14 known issue:

- text property changes doesn't set the room changed flag (bypass: change something else, such as the room/hotspot description in the room and save)

If you come across anything else, let me know.

I came across what appears to be a bug.

My module reads out hotspot/object/character/item text properties for inserting in a label (so you can have a custom text appear in in when moving over the correct button etc.)

I added some hotspot text properties, which goes fine, but when I change the text later on, the editor seems to accept (save) the new texts, but when I launch the game it still displays the old text. If I save and restart the editor, the properties indeed still shows the old text.

Am I missing something here? I don't mind if the values of custom properties are non-changable during gameplay, but being non-changable during editing???