Oolite Bulletins

And here is the output of the test case: Ouch!

Well, that at least means it’s not Oolite breaking something. :-) I’ll ask on gnustep-dev, then.

Edit: No, I won’t, because there’s a newer binary release - 1.13.1.

I found something interesting. Taken straight from the headers of gnustep-base 1.13.1, NSString.h, just above the fileSystemRepresentation declaration:

* NB. On mingw32 systems the filesystem representation of a path is a 16-bit unicode character string, so you should only pass the value returned by this method to functions expecting wide characters.

I think what happens is that JS_CompileFile expects a const char* as argument, but receives a wide character string instead and gets confused.
So, I guess we are only left with the UTF8String solution for Windows.

• I’ve completely rewritten JavaScript loading in a way which avoids the issue, and is also Unicode-savvy (although the only place you could reasonably use Unicode would be in comments.)
• I’ve also renamed all the built-in world scripts so their names start with “oolite-”. Unless someone’s written an OXP which replaces one of the buit-in missions, this shouldn’t be a problem.
• It is now possible to set uniforms for shaders in shipdata.plist. This means that a single shader can be shared between multiple ships/entities, with small parametric differences. For example, in Freaky Thargoids for 1.67, the two ships had shaders which were identical except that one multiplied the time by 1.5 to get faster animation. In 1.68, they can share a shader and configure the difference in shipData.plist:

  Code: Select all

  <key>shaders</key>
  	<key>thargon_redux.png</key><!-- replace this texture -->
  	<dict>
  		<key>textures</key>
  		<array>
  			<string>thargon-base.png</string><!-- passed as tex0 -->
  			<string>thargon-glow.png</string><!-- passed as tex1 -->
  		</array>
  		<key>fragment_shader</key>
  		<string>freaky_thargoid.fragment</string>
  		<key>vertex_shader</key>
  		<string>freaky_thargoid.vertex</string>
  		<key>uniforms</key>
  		<dict>
  			<key>reciprocalFrequency</key>
  			<real>1.5</real> <!-- 1.5 for thargon, 1.0 for thargoid. -->
  		</dict>
  	</dict>
  </dict>

  This simplifies coding and reduces OXP size; it also has the potential to be more efficient, although currently it isn’t. Uniforms can currently be a single float or a single int; if the value is specified directly, it is assumed to be float (regardless of whether you use <real> or <int>), but you can specify type by using a dictionary:

  Code: Select all

  <key>uniforms</key>
  <dict>
      <key>myUniform</key>
      <dict>
          <key>type</key>
          <string>int</string> <!-- May be int or float; other values cause the uniform to be ignored. -->
          <int>42</int>
      </dict>
  </dict>

Just one more waffer-zhin feature, and some testing… 1.68 will be ready tomorrow.

Good job, Ahruman. You're not really living up to your 'Lazy Programmer' title with this flurry of activity

Captain Hesperus

Just you wait… in another month I’ll seem all reliable, then I’ll crash and wander off to do something different for a year.

Flying_Circus wrote:

Excellent work, if I may say so.

I can only reiterate the above!

Will all these improvements be available for the PC version as well?

There will be a Windows release, hopefully also tomorrow. We don’t have an active Linux maintainer at the moment.

Great news!

Ahruman wrote:

Just you wait… in another month I’ll seem all reliable, then I’ll crash and wander off to do something different for a year.

It happens to the best of us! Looks like we'll have to get the goods out of you before the big breakdown then

Captain Hesperus

Discovered that Strict Mode is broken. Tried to fix it, and discovered that it’s very broken. The absence of bug supports suggests no-one uses it, although it’s possible it would work if you didn’t have any OXPs installed. Will not be fixed for 1.68.

Guess I should read this list more often. I love strict mode! But then I'm a retro grouch. How complex is the strict mode code? Could we use the momentum feature (where nothing stays still in space) outside strict mode?

I’d rather try to fix it for 1.69.

Dear diary, today… er, mostly yesterday… I have implemented vector maths for JavaScript, as provisionally documented here. From a coding perspective, making expressions like “player.position.x += 5000” work was interesting, but went surprisingly smoothly. I have no idea whether it will port well, though. It could be that it needs to be done in an entirely different way for the GNU-gcc ObjC runtime.

A broader issue is whether it should be possible at all. On the one hand, it provides greater flexibility to scripts; on the other, it’s not immediately clear whether setting entities’ positions directly is actually useful for anything other than cheating. But then, if there’s one thing we can be sure of it’s that the community will find some creative, worthwhile and probably quite spectacular use for it that we never would have thought of.

I’m somewhat in favour of leaving it in purely because of the twisted elegance of the implementation. :-)

More JavaScript work: working on Entity class. Scripts will never work with “raw” entities, but rather with derived types such as Vessel and Planet. Player will be a type of Vessel.