Ben Russell

Thanks for the info. The repo browser has been broken because I am preparing a polished release version that is overdue. The files it reads have changed format slightly. The good news is that it's pretty easy to get back to an old version that should work. Copy and paste this: 9492c1e8bdbb into the repo browser where replacing the word "tip". You are telling the repo browser that you want a specific version number of the scripts from the bit bucket servers. Click update and it should give you a list.

Thanks for the report. Quite odd. Both SASL and Gizmo use Lua at their core, clashes have been widely reported. That have a version that doesn't clash is what puzzles me. Solutions are known but Gizmo is a very complex plugin so implementing them on 4 platforms is less than fun. (Yes, four. PowerPC-Mac, Mac, Windows, Linux) Do you run Mac or Windows?

In the words of a great man: Yah. Yah.

This video shows a working prototype of filter chains and a GUI visualization of the chain graph. It also features a graphing "scope output" that can be used to inspect the chain at various points to ensure the data stream is doing what you want.

the paper tape based computer they built in WW2 to decode the german signals was bested by a Pentium 2 class "general purpose" computer. that's how.

_G table is also dangerously useful.

Great!

I don't understand your block. Gizmo is designed to let you get on with the core of your problems directly. Have you seen the F-16 sample? It's kinda buried... https://bitbucket.org/xplugins/gizmo-f-16/ The F-16 has multiple EFIS instances running off the same core modules. It's not very good scripting, but it explores some ideas. It may help you. I don't want to rain on your parade, I just don't really understand your real objectives. You seem to want some kind of runtime module loading.... Lua allows this sort of thing _way above_ the file level. I consider the fact that Gizmo wants to load and verify as much as possible in one go an asset, it helps track down errors and avoids "dynamically generated code states" which are just about impossible to debug. Bad repeatability. Gizmo itself is designed to open X-Planes doors quickly and easily. It needs, and I am working on, some nice Lua frameworks to sit on top, to manage things like sharing of the Drawing functions, etc. These are pretty simple things to write and can do a lot in very little code. Feel free to shoot me a PM/email (br@x-plugins.com) with what you want to achieve... I can probably offer some help.

You are now leaving the supported path. There is only so far I can go. If you wish to start hacking the guts of Gizmo and my design principles, when they are working for everyone else.... Good luck.

Ok... I had assumed require was a stringent version of dofile()...... I'll check this problem out. It may also be a problem with the time during execution that you're firing this command. Gizmo jumps into your aircraft/scripts/ folder, loads everything, and then jumps out again. You're only in that folder for a fraction of a second after the ACF is loaded. If you're trying to do delayed loading you're probably looking for Lua files in the same folder as X-Plane.app/.exe which won't work.

No. If the error checker appears the Lua state is considered broken. Calling a Lua function that may be broken to handle an error about Lua being broken is....... not the best idea. How do I know it's not your error handler that's broken? I don't believe Gizmo does anything directly to circuit-break when the error dialog goes off. If things stop working it's because the Lua engine is scrambled. All Gizmo wants to do is throw the error in an attempt to help you write bug free modules as quickly as possible. It seems from where I stand that you are spending a lot of effort re-inventing things Lua already gives you, or has recommended design patterns for. Have you read the chapter/documentatiom on require() and Lua module patterns? A genuine question.

X-Plane 10 has been delayed because Tom Kyler was admitted last night suffering a severe case of Gizmo Addiction. Sorry everyone. :-\

http://www.opengl.org/sdk/docs/man/xhtml/glScissor.xml

Please Stop Using Short Names. You have overloaded the built in Lua function load() ..... and you basically break everything from there on. http://www.lua.org/manual/5.1/manual.html#pdf-load Please, use globally unique, long, variable names, the time it takes to doo x500eclipse_Load() is far less than you have spent on debugging. Thanks. I'm glad we hit the solution, eventually. I do not know Lua extensively yet. Sorry I couldn't just give you this one.

Programming is hard. The smallest grain of sand can bring you to an abrupt halt. Do not be discouraged.

So far it has been a matter of unpicking a few things. As the problem unwinds we are seeing Lua Syntax errors that would affect any Lua script run in any game or app. We're still resolving the original post which does seem a little strange, there was nothing that stood out as an obvious error. At this point I'm wondering if the keyboard map that pinkfloydgeek is using is doing something with " characters, but they seem to come through ok in the forums. This is quite puzzling. Sometimes a compound error can mask the true cause. Error messages can be a few lines off because you didnt finish up your last statement correctly, etc. I recommend testing your scripting as often as possible in a tight loop until you get a good grasp of Lua. It's very quick easy and rewarding to test things out with the sim running. I appreciate you want to work on the bigger framework to though. As we have many artists working with many different and complex scripts, some of them quite large and containing several string literal variables, I don't think it's likely to be a direct problem with Gizmo, just a strange quirk that we need to document. Unfortunately, in todays world, all text editors and text files are not equal and a " might not actually be a ". *sighs* Keep posting until you resolve it pfg!

string.format takes an unlimited* number of variables. Change your code: Log(string.format('Module "%s" loaded'), path) To: Log( string.format('Module "%s" loaded', path) )

95% of bugs are 1 char issues like that, and we don't have a strict compiler to check it all.

Strongly recommend the use of longer more clear variable names, that stuff will be very hard to maintain or collaborate on. :/

elseif not exec and UnmountFlag == true then Log("Module "..ppath .." unmounted") .......you can copy and paste the error message out of Gizmo, I'm not sure if you have..... hopefully the above is all your problem is. (All text widgets in gizmo get clipboard functionality free) This is a general Lua syntax error. For future reference I strongly recommend the use of string.format() to glue variables together, it's more tolerant of nil values or strange var-types. a = string.format("foo: %s %i %0.3f", "abc", 1, 2.345) Good luck, let me know if this sorts you out!

It's going to take a little while to put together a meaningful answer to this question, please stand by... Not ignoring, just busy!! Thanks!

(Most of these demo's are just quick hacks to test out features, apologies for the quality of script code.) puff_texture = gfx.newTexture() gfx.loadTga( puff_texture, xp.getAircraftFolder() .. "puff.tga" ) function init_particles() local mist_count = 2000 local mist_life = 5 local mist_birth_rate = 10 local texture = puff_sprite local size=0.25 local color = {0, 1, 0, 0.5} local scale_rate = 1 local emax = 1 local emin = 0.1 local gravity = 1 local left_tip_particles_enabled = true if(left_tip_particles_enabled)then ph_left = particles.new() particles.setCount( ph_left, mist_count ) particles.setLife( ph_left, mist_life ) --life span in seconds particles.setBirthRate( ph_left, mist_birth_rate ) particles.setTexture( ph_left, puff_texture ) --212 = black particle, 224 aurora, particles.setSize( ph_left, size ) --size at birth along an edge particles.setColor( ph_left, color[1],color[2],color[3],color[4] ) particles.setScaleRate( ph_left, scale_rate ) particles.setEnergyMin( ph_left, emin ) particles.setEnergyMax( ph_left, emax ) particles.setGravity( ph_left, gravity ) particles.setType_Spherical( ph_left ) particles.start( ph_left ) --particles.setDisabled( ph_left ) logging.debug("Started particles: ph_left") end end init_particles() function OnDraw_World() --logging.debug("Drawing particles..") local x,y,z,p,r,h = gfx.getAircraftPositionGL() local gx,gy,gz, gnx,gny,gnz, gvx,gvy,gvz, gwet = xp.getTerrainData( x,y,z ) --the wash disc size can never be smaller than our rotor foot print + conical divergence over ~10 ft. local wash_disc_size = acf.getAltAgl() local wash_disc_min = 20 if( wash_disc_size < wash_disc_min )then wash_disc_size = wash_disc_min end --local terrain_info_tip_tail = {xp.getTerrainData( weps_x[1], weps_y[1], weps_z[1] )} --gl.PushMatrix() --gl.Translate( weps_x[4], weps_y[4], weps_z[4] ) gfx.setColor(0,1,0,1) --if( show_fp_dbg )then gl.Begin('LINES') --gl.Vertex( 0,0,0 ); --gl.Vertex( 0,-(v_nose),0 ); gl.Vertex( x,y,z ); gl.Vertex( gx,gy,gz ); gl.End() --gl.PopMatrix() --draw a line from our airframe down to the ground plane gl.Begin('LINES') gl.Vertex( x,y,z ); gl.Vertex( gx,gy,gz ); gl.End() --draw a circle on the ground that will contain our particle effect. gl.PushMatrix() gl.Translate(gx,gy,gz) gl.Rotate( 90, 1,0,0 ) gfx.drawCircle( wash_disc_size, 60 ) gl.PopMatrix() local fixes = {} --calculate some dust noise for i=1,50 do fixes[ #fixes+1 ] = { trig.newPositionOffset( 360 * math.random(), wash_disc_size * math.random() )} end if( not xp.getPaused() )then if( ph_left ~= nil )then --particles.setColor( ph_left, math.random(),math.random(),math.random(),1 ) --particles.setOrigin(ph_left, x, y+1, z ) --particles.setOrigin(ph_left, gx, gy, gz ) -- [[ for i=1,#fixes do --draw a line from our airframe down to the ground plane local f = fixes[i] local rx=f[1] local ry=f[2] -- [[ gl.Begin('LINES') gl.Vertex( gx+rx, gy, gz+ry ); gl.Vertex( gx+rx, gy+1, gz+ry ); gl.End() particles.setOrigin(ph_left, gx+(rx/2), gy, gz+(ry/2) ) --]] end --]] local alt_fx_p = acf.getAltAgl()/20 if( alt_fx_p > 1 )then alt_fx_p = 1 end local inv_p = 1 - alt_fx_p particles.setGravity( ph_left, inv_p*2 ) particles.setLife( ph_left, inv_p*5 ) particles.setSize( ph_left, inv_p*2 ) particles.setScaleRate( ph_left, inv_p ) --sound.say( inv_p ) end end end

Gizmo is now Linux Compatible. Gizmo has been compiled and tested on Ubuntu 10.10 Expect a linux release of Gizmo tommorow. 2010.11.22 along with a release of updates for Mac and Windows. Gizmo now works on all three operating systems and will provide cross platform scripting ease as of tomorrow. Here's a screen shot to keep you happy:

This example shows loading and drawing some OBJ8 objects with code. 77 lines. https://bitbucket.org/xplugins/gizmo-sdk/src/tip/examples/misc/BouncyObjects/BouncyObjects.lua

Sorry for the confusion, any changes are made in the name of making you a sleeker, faster, better product. Thanks for posting so that we can all learn from these things. Myself included.