Okay, figured out why cars can pick up flags and stuff in Puff-Puff, it's not technically a bug.  Sphere 1.x only calls the touch-script for input person collisions, minisphere does it for all entities.  Despite that the behavior is not fully compatible, in almost all cases, minisphere's semantics here are preferable.  Persons should be able to respond to anyone touching them, not just the player(s).

For Puff-Puff specifically, the workaround is to add this line to the top of the relevant touch scripts:

Code: (javascript) [Select]

if (GetActivePerson() != GetInputPerson()) return;

So yeah, I think that's all the Puff-Puff bugs, time for 1.4.2!

edit: minisphere 1.4.2 is up.  This fixes an incredible number of bugs, so make sure to check the changelog.

Lookie here:
https://travis-ci.org/fatcerberus/minisphere

Okay, figured out why cars can pick up flags and stuff in Puff-Puff, it's not technically a bug.  Sphere 1.x only calls the touch-script for input person collisions, minisphere does it for all entities.  Despite that the behavior is not fully compatible, in almost all cases, minisphere's semantics here are preferable.  Persons should be able to respond to anyone touching them, not just the player(s).

Despite being incompatible I do like this system. It makes making a RPGMaker like eventing system easier to manage if other entities collisions can be handled gracefully. Otherwise it'd be hard to get back that kind of info without running your own loop of checks (which is rather redundant), and prone to failure.

Lookie here:
https://travis-ci.org/fatcerberus/minisphere

Nice! I suppose this will warn you of building issues before I get the chance to complain () about it, right?

Lookie here:
https://travis-ci.org/fatcerberus/minisphere

Nice! I suppose this will warn you of building issues before I get the chance to complain () about it, right?

Yes, plus it paves the way for a future official Linux release, as I'll know ahead of time whether the build is broken (so errors don't pile up).  What shocks me is how *silent* the build is, even in the clang build.  No warnings whatsoever.  I wonder what warning level SCons is using...

It looks like the clang build is working in GCC compatibility mode, which is very permissive by Clang's standards.

Try adding CFLAGS=" -Wall " and you will get a barrage of new warnings, and " -pedantic " if you are feeling truly masochistic.

I'm just going to go out on a limb here and guess that -pedantic will make the build horribly, horribly broken.

"-pedantic" makes the build 99.9% accurate to the standard you selected (which defaults -std=c99). Clang and GCC are far closer to the C99 standard than MSVC is (or really any other compiler except for Solaris Studio), so I would suspect that it bring up all kinds of new and exciting problems.

You can also add "-ansi" instead of "-std=c99" to get C89, which is very close to what MSVC 2010 has, except that it also disallows single-line comments. C99 didn't really work at all until at least MSVC 2012.

I'm not giving up C99, I like my // comments and sized ints too much.

Well, sized ints are a matter of the library itself, not the standard. While technically a compiler should limit the library a program can see when compiling for a certain standard, this tends to only happen with C++.

Then there's Solaris Studio. (Almost) fully C++14 and C11 compliant, still running on a C++03 and C89 library :/

Thanks a TON! It is unbelievable how fast you update and commit.
Good code too, will re-test stuff later-on.
I'm trying to get the networking working, but I seem to either not "getting" it, or there is a bug:

Code: [Select]

  var LocalPort = 9500;
  var Listen = 255; // MAXCONNECT
  var server = new ListeningSocket(LocalPort, Listen);
  if(! server ){Abort("Could not open socket on " + LocalPort)}
  var socket = server.accept();
  if(socket === NULL){Abort("Could not accept socket")}
  if(socket.isConnected()){
    var len = socket.getPendingReadSize();
    if(0 < len && len < 1024){
      var BUFFER = socket.readString(len);
      socket.write("404 Not Found\n\r\n\r");
      Abort(BUFFER);
    }else{
      Abort("len is not ok " + len);
    }
      socket.close();
  }

But for

Code: [Select]

var socket = server.accept();

it throws:

Code: [Select]

JS Error: main.js:10 - TypeError: not callable

I wrapped it in a try loop, of course, but even then, a webbrowser connects, but then "hangs" (as opposed to an immediate "unable to connect" error). So we know it is connecting, but it seems it is not able to start up communications.

I'm not giving up C99, I like my // comments and sized ints too much.

Wall is allright, and with pedantic... wow...  don't even try it...

obj/utility.h:6:8: warning: (this will be reported only once per input file)
In file included from obj/animation.c:2:0:
obj/api.h:1:14: warning: ISO C forbids forward references to 'enum' types [-Wpedantic]
typedef enum js_error js_error_t;

(and of course, a waterfall of similar stuff)

Still, some things are worthy of checking out with Wall,

Code: [Select]

CFLAGS = ["-Wall", "-std=c99"]
minisphere = Program("msphere", msphere_sources, LIBS = msphere_libs, CFLAGS = CFLAGS)

Thanks a TON! It is unbelievable how fast you update and commit.
Good code too, will re-test stuff later-on.
I'm trying to get the networking working, but I seem to either not "getting" it, or there is a bug:

Code: [Select]

  var LocalPort = 9500;
  var Listen = 255; // MAXCONNECT
  var server = new ListeningSocket(LocalPort, Listen);
  if(! server ){Abort("Could not open socket on " + LocalPort)}
  var socket = server.accept();
  if(socket === NULL){Abort("Could not accept socket")}
  if(socket.isConnected()){
    var len = socket.getPendingReadSize();
    if(0 < len && len < 1024){
      var BUFFER = socket.readString(len);
      socket.write("404 Not Found\n\r\n\r");
      Abort(BUFFER);
    }else{
      Abort("len is not ok " + len);
    }
      socket.close();
  }

But for

Code: [Select]

var socket = server.accept();

it throws:

Code: [Select]

JS Error: main.js:10 - TypeError: not callable

I wrapped it in a try loop, of course, but even then, a webbrowser connects, but then "hangs" (as opposed to an immediate "unable to connect" error). So we know it is connecting, but it seems it is not able to start up communications.

Oops, I accidentally still had accept() exposed as "acceptNext" from when I originally implemented the Sockets API.  The latest Git build fixes it.

If -Wall is fine but pedantic is broken, you could also try -Wextra, sort of in between.

...but ideally I suggest at least looking at the output of pedantic.

Amusing side note: Don't ever attempt to use -Wall with MSVC.  It generates thousands of "warnings" that aren't even real warnings--noise like "Oh hey, I inlined this function for you" or "x amount of padding added to this struct" and other such nonsense.