Messages

Thanks! You're welcome CW!

I've fixed the link in the first post btw. Still a ton of broken links out there I guess.

[edit:]

All of my Dropbox accounts are filled to past the brim unfortunately. Hmmm,... Google Drive might be an option; I can make a new gmail account for that I guess. I'll look into that! Thanks all for the suggestions.

edit:
All updated! I've counted: this is the fifth time I had to swap over files to another host; pretty please Google, don't fail me. I can't stand doing it once more.

Unfortunately, GitHub is only free to use for open source projects, which this is as yet not, for reasons mentioned before.
Any other suggestions perhaps?

Yes, I've heard about problems with Xbox 360 controllers left and right, and it is really puzzling because: one day it's all working fine, and then suddenly it is not. I even had people with multiple Xbox controllers where one never worked, and then suddenly it started working but the other one stopped. I'm not really doing anything special, and I'm simply using what Windows provides. There is something weird going on with the combination of AGS and the Windows drivers, but it is extremely difficult to pin down. Even more so since I don't own a Xbox controller, so I can not test it myself.

Wyz! The d-pad (POV) in my wired Xbox360 joystick doesn't work. Do you have any idea why?

Is there any possibility of releasing the joystick plugin source? I would like to play with maybe porting it to Linux.

The POV value does not respond to the D-pad at all? Hmmm, sometimes the D-pad is implemented as an analogue stick, so be sure to check all the axes. In rare cases the D-pad is implemented using buttons; be sure to check those as well. If none of the above respond to the D-pad something is amiss. Could be more Xbox controller shenanigans.

....maaaaybe you should find a different host for that

Sure; do you have suggestions?

Thanks for the updated version! I'll add the link to the first post if you don't mind.

Yes, after the last update the problems with storing and restoring games should be fixed. Additional code before saving and after loading games should technically not be required.
But indeed I do recommend a bit of code when games are restored. I find it hard to provide a general solution as it really depends on how you design your game. But let me give two examples; maybe this helps someone.

Game A
Game A is a single play game which can be played either by keyboard or optional a game controller. When the game starts it scans for available game controllers, and opens every one it finds. The keyboard inputs and the inputs from all controllers are mapped to the same outputs; for instance ASWD, the arrow keys, the d-pad of whichever joypad is connected, or the stick of some joystick connected: they all control the character's movement. In short, no configuration, the kind of setup I would describe as "just works".
Now imagine the player restores a saved game; at this point game controllers may have been connected or unplugged. If you don't do anything "just works" becomes "doesn't work" because Joystick objects from unavailable game controllers stop firing events, and newly connected ones are not being considered.
In that case I recommend you'd close all open Joystick objects, and run the same scan as at the beginning of the game again.

Game B
Game B is a multi-play single screen game which can be played by mouse, keyboard, or game controllers. At the beginning of the game each player selects an input device from a list of available ones (mouse, keyboard, optional game controllers). During the game players can open a menu which allows them to reconfigure (change the meaning of buttons of) their selected input device, or pick another one.
Now imagine the players load a stored game; at this point game controllers may have been connected or unplugged. It could be the case that one of the players uses a device no longer available.
In that case I recommend showing a warning when one of the Joystick objects has become invalid (scan through them at game restore), or perhaps open the configuration screen automatically.

Other options are possible of course; these are just examples.

Yes the plug-in is 7 years old, so is the tutorial. Thanks for fixing the backwards compatibility CW!
I need to update and re-upload it someday (without crash dumps ) but still my time is fairly limited. I rather first make a complete port, which is a little more involved. For now you'll have to do with the files as is, sorry.

Well, the plug-in should never crash the game when restoring a save game that has a different joystick setup; when that happens you can consider that a bug in the plug-in, and then please let me know. When a Joystick object you made becomes invalid for whatever reason, it is replaced with a dummy object that acts like a joystick but is frozen in time. However I recommend the check to make sure the players aren't confused about the situation.
For instance when you have a single joystick setup and you let the game find (or players pick) one at the start of the game; when the players restore a game and have inadvertently changed their joystick setup you'll want to repeat this bit. If you have a game where the joystick use is optional and players have to select it in a menu or something, you'll want to show them a warning things changed and they may want to reconfigure it.
Of course I'm not telling you how to build your game, but since this matter came up, I thought I'll just give you the tip.

So I think I've fixed it now. You can download it here (temporarily). Let me know if it works.

Btw, special thanks go to CW for suggesting to use a virtual joystick in the other thread; that really sped things up, as I didn't have to crawl through the attic opening lots of boxes, trying to find my gamepad. Thanks!

Ok, I finally got round to test this myself and good news: I was able to replicate the error. I should be able to fix this relatively easy.

You should probably still do something when the game is restored (using on_event). When the game is restored and the plugin misses it, it will be marked invalid. You can test this by checking the Valid function. A good moment to reset the input configuration, or inform the player, or something.

I'll keep you posted.

I've compiled a new version of the plug-in and uploaded it here (temporarily).
Kindly give it a go and see if it works.

If so I'll re-release it then. (although I don't have a place to host such things anymore unfortunately)

Let me know and thanks for your feedback.

Hmmm, I guess this is a bug of some kind. Every plug-in object is serialized--turned into a data blob which is added to the save file--when the game is saved. When the game loads again the plug-in is then responsible for unserializing the objects, basically do whatever to make it work again. Looks like something goes wrong at the unserializing stage. I store the joystick state (which buttons are down etc) and the joystick's name. When the game loads again the state is restored and the plug-in checks whether the joystick's name has changed. It either is no longer present or the order of joysticks plugged in has changed; in both cases the object is invalidated.

That said I do have an idea what might be causing this. Which exact version of the plugin are you using?

Spoiler

I seriously need to revisit this plug-in; reading that poorly written manual alone made me cringe.

[close]

I noticed that the links in the first post were broken so I have re-uploaded both the plugin and the tutorial. Feel free to check them out! Oh, and if you do, please let me know as well; I'm curiousness myself whether they still work.

As for the source code: that is currently a complete mess so I can't really release that. I will probably revisit that someday in the future, there is also half an Linux port in there, but still a lot of work to get it up and running unfortunately.

[Note:]

Yes, I might as well release it as I'm pretty much done with it.

AGSadplug source at GitHub

Be aware that not stopping playback potentially well have the sound resonate indefinitely; that wouldn't be very nice.
You can get the same effect btw by setting the tempo to zero just before the song ends. That way you probably do not have to alter the plugin. Otherwise, have a look somewhere around here.

Note: If you do alter the plugin and are planning on releasing it in some form please add a suffix to its name. That way we can prevent potential clashes regarding incompatible plugin behaviour.

I hope that helps you.

Hmm, the released joystick plugin uses winmm; I was working on a new version that uses directX, but I open a new interface there. Partly also because I want it to be cross-platform, so I had to make an abstraction layer anyways.
The other plugins I've released don't use the interfaces I believe. I was working on a screensaver plugin a while back that uses the direct draw interface, but that is unreleased and also very hacky . Access to the directX interfaces is nice and efficient for e.g. drawing but not cross-platform so I've been trying to work around it.

Has it already been three years? Ouch.. Well it is still on my mind and I do want to finish the alpha at some point.

As Snarky pointed out: there are two plugins. The one used for the ceremony was made specifically for that purpose, and does not have a really reliable buffer. Fine for IRC (what it was used for) but probably unstable for more intense uses, especially when using binary protocols. That's why I set out to make a new plugin that is fully threaded. In fact the alpha already has most basic functionality in, and that part is stable. I had a quick peek at the source: binary messages/data and socket options are not yet implemented, the rest more or less is, and the API is not likely to change.

The warnings are there because a clear versioning system has not yet been put in: when I release a new version I can not guarantee previous games will break especially when those DLLs start floating around on the web. If you're just making a prototype you can ignore the warning and use the alpha. If you want it to be part of a more serious release you could use the old plugin (depending on what the protocol requires). There is also an in-between solution: I could compile a special version of the alpha you could use for a release; the functionality would not differ.

Anyways, yes, I want to finish it and release it properly, but since I'm pretty busy these days, it might take a while before I'll have time; probably June or July.

I hope that works for you!

And I saw your PM btw: I though I'd better just respond here I case some folks were wondering too

The first things that springs to mind is Minecraft; they're just about the right age to play that and it allows to create your own 'adventurous hikes' with clues and and whatever you come up with in an interactive relatively safe environment. I don't know how well it works given the topology and connection wise but that would be my suggestion.

Thanks guys!!!
Survived another decade

Hah, teaches me not to post code that is untested. There is a copypasta mishap on line 38; get rid of the i++ there and it should work.

Well, it looks like you're out of luck: the archive does not contain the exe file at all and you do need one to run the game. Try contacting the original authors of the game and also point out that there is a version out there without all the required files. I'm sure they are interested to know that.

Let's hope they fix it.

Hmm yes that function does not regard axes as it is. It is possible to do so however but it is not trivial; you need to check for movement rather than a position. I've come up with a function but I did not have time to test it so let me know if it works or not.

Code: ags

// Amount of movement that triggers it, play with this
// Find a middle ground that does not only work for your controller
#define JOY_THRESHOLD 8192

function WaitMouseKeyJoyAxes(int time, Joystick *j)
{
  int buttons = j.buttons;
  int p[] = new int [j.AxesCount];
  
  int i = j.AxesCount;
  while (i > 0)
  {
    i--;
    p[i] = j.GetAxis(i);
  }
  
  while (time)
  {
    if ((j.buttons ^ buttons) & j.buttons)
      return (1);
    else
      buttons = j.buttons;
    
    i = j.AxesCount;
    while (i > 0)
    {
      i--;
      
      int axis = j.GetAxis(i);
      int disp = axis - p[i];
      
      if (disp < 0)
        disp = 0 - disp;
      
      p[i] = axis;
      
      if (disp >= JOY_THRESHOLD)
        return (1);
    }
    
    if (WaitMouseKey(1))
      return (1);
    
    if (time > 0)
      time--;
  }
  
  return (0);
}

I hope it helps.

Thanks for your feedback, I appreciate it!

Hmmm the naming clash should not occur; I saw someone else with a similar problem so I'm going to look into it.