pipmak-devel — Development of the Pipmak Game Engine

Re: [pipmak-devel] Pipmak for iPhone and/or PSP

[IrishRed863 <ps....@gm...>]

I've used FMod and Torque 2D, to name two well-known external libs, in iPhone
apps that were approved by Apple. While Apple reserves the right to reject
an app, they apparently do not tend to do so on those grounds alone. In
fact, during the license process the FMod guys reported that they've not had
a single iPhone licensee have a rejected app yet.

I realize the presence of an interpreter may be a little different, but I
think (and may be wrong here) that Torque is also running an interpreter for
its script.

Just additional data points on this topic.




jcowen wrote:
> 
> Thank you gentlemen. That makes perfect sense... what a shame...
> 
> JC
> 
> 
> Christian Walther wrote:
>> 
>> jcowen wrote:
>>> how difficult would it be to create a version that runs on the  
>>> iphone? or perhaps the PSP?
>> 
>> Technically, I'd expect an iPhone port to be feasible, and it's  
>> actually on the list of things that I'd like to do sometime...
>> 
>> There is, however, a political problem, as Aidan has already  
>> mentioned: Even if I do port it, I won't be able to publish it as a  
>> standalone application, because it violates Apple's SDK conditions:
>>    -Christian
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Pipmak-for-iPhone-and-or-PSP-tp21617842p24635730.html
Sent from the pipmak-devel mailing list archive at Nabble.com.

Re: Development of Video on Pipmak

[Christian W. <cwa...@gm...>]

valerian.g writes:
> I have started to get the SVN version of Pipmak and began to install it
> following the wiki page made by Andrea Viarengo.

So you're using MS Visual Studio? As you can see, we currently don't have
VS projects in SVN. If you get yours into a sufficiently generic state to
run on anyone's computer (no hardcoded absolute paths etc.), I'd be
interested in including it.

> Are the version of library describe in the wiki, the ones we must use,
> because they are not the latest version and for the moment I take the
> latest.

Let me check - I haven't updated any of my libraries since the last
release. Pipmak 0.2.7 was built with SDL 1.2.13, SDL_image 1.2.6, SDL_ttf
2.0.9, PhysicsFS 1.0.1, Lua 5.0.3, OpenAL 1.1, libogg 1.1.3, libvorbis
1.2.0.

Current versions (where different) are SDL_image 1.2.7, PhysicsFS 1.0.2
(2.0.0 may or may not work - but thanks for bringing it to my attention,
it seems to have some useful new features!), libogg 1.1.4, libvorbis
1.2.3. These all seem to be minor updates and should work. Don't use Lua
5.1, it has a few syntactic changes compared to 5.0 and I intend to
switch to it with Pipmak 0.3.

 -Christian

Re: [pipmak-devel] Development of Video on Pipmak

[valerian.g <val...@fr...>]

Thank you Christian for your quick reply.
I think we will keep Theora first as it is in the same line as Ogg vorbis
for sound.
I have started to get the SVN version of Pipmak and began to install it
following the wiki page made by Andrea Viarengo.
Are the version of library describe in the wiki, the ones we must use,
because they are not the latest version and for the moment I take the
latest.
Let me know if i must rollback my installation.
Val

-- 
View this message in context: http://www.nabble.com/Development-of-Video-on-Pipmak-tp24539471p24542166.html
Sent from the pipmak-devel mailing list archive at Nabble.com.

Re: Development of Video on Pipmak

[James W. <jfc...@ya...>]

Superb! I hope you succeed, and I look forward to your game!
Any development window planned? I don't mean to push you, just curious.
 
Thanks,
  James

--- On Fri, 7/17/09, val...@fr... <val...@fr...> wrote:


From: val...@fr... <val...@fr...>
Subject: Development of Video on Pipmak
To: pip...@li...
Date: Friday, July 17, 2009, 2:25 PM


Hello,

I represent a french team developing a free game using Pipmak engine.
We know that the video integration is not yet done for Pipmak.
However, we’re going to really need this feature and it’s the reason why we
offer our services to develop voluntarily this feature for Pipmak.
We noticed the first video implementation you  would like to do is for Ogg
Theora.

Would you be interested by our proposal ?
Do you have a development standard to give us ?
Have you started to work on this implementation ?
If you haven’t, have you thought about it and what are your advices ?

Thanks for reading and above all thank you for this amazing game engine !

Val


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Pipmak-Devel mailing list
Pip...@li...
news://news.gmane.org/gmane.games.devel.pipmak.devel
https://lists.sourceforge.net/lists/listinfo/pipmak-devel



      

Re: Development of Video on Pipmak

[Christian W. <cwa...@gm...>]

Hello Val

> I represent a french team developing a free game using Pipmak engine.
> We know that the video integration is not yet done for Pipmak.
> However, we’re going to really need this feature and it’s the reason why we
> offer our services to develop voluntarily this feature for Pipmak.

That would be very welcome! Video support is about the most requested feature
currently, it's quite a chunk of work (I assume), and as you may have noticed
I have been busy with a lot of other stuff besides Pipmak lately.

> We noticed the first video implementation you  would like to do is for Ogg
> Theora.

I don't insist on that, it's just what seemed easiest to me, at the first
glance. I'll accept anything, as long as it's GPL-compatible,
non-patent-encumbered, and runs at least on Mac OS X, Windows, and Linux.

> Would you be interested by our proposal ?

Sure! Even if, hypothetically, it shouldn't turn out to my liking, I think
having something is better than nothing, and it can always be improved later.
So, contributions are welcome. And, of course, you're free to do it any way
you like for your own use (within the licence), no interest or permission
from my part required.

> Do you have a development standard to give us ?

Not really. There's a short document about the general architecture at
<http://pipmak.sourceforge.net/wiki/index.php/Notes_on_Pipmak%27s_architecture>
(will probably move to
<http://sourceforge.net/apps/mediawiki/pipmak/index.php?title=Notes_on_Pipmak
%27s_architecture> soonish). In terms of code style, just stick to the style
of the existing code. Once your code makes it into the official trunk, you
will have to live with me messing around in it to adapt it to my ideas (which
develop as I go), but I try to do that in a cooperative way. ;)

In general, I'd say, just go for it, and we can discuss specifics as they
come up. I'm here to help. You're welcome (even encouraged) to use this
mailing list for discussions, and once you have posted something that shows
that you're serious about completing this, I could give you an SVN branch to
work in too, if that's desired.

> Have you started to work on this implementation ?

No.

> If you haven’t, have you thought about it and what are your advices ?

I haven't spent a lot of thought on it. My general idea is that, in the Lua
interface, movies should be objects as similar as possible to images (just
with methods like play, stop, go to a specific frame...) and should be
accepted everywhere images are accepted (patches, node backgrounds).

Thanks for your interest, and let us know about the progress of your game
too!

 -Christian

Development of Video on Pipmak

[<val...@fr...>]

Hello,

I represent a french team developing a free game using Pipmak engine.
We know that the video integration is not yet done for Pipmak.
However, we’re going to really need this feature and it’s the reason why we
offer our services to develop voluntarily this feature for Pipmak.
We noticed the first video implementation you  would like to do is for Ogg
Theora.

Would you be interested by our proposal ?
Do you have a development standard to give us ?
Have you started to work on this implementation ?
If you haven’t, have you thought about it and what are your advices ?

Thanks for reading and above all thank you for this amazing game engine !

Val

Re: [pipmak-devel] Pipmak for iPhone and/or PSP

[jcowen <jc...@ma...>]

Thank you gentlemen. That makes perfect sense... what a shame...

JC


Christian Walther wrote:
> 
> jcowen wrote:
>> how difficult would it be to create a version that runs on the  
>> iphone? or perhaps the PSP?
> 
> Technically, I'd expect an iPhone port to be feasible, and it's  
> actually on the list of things that I'd like to do sometime...
> 
> There is, however, a political problem, as Aidan has already  
> mentioned: Even if I do port it, I won't be able to publish it as a  
> standalone application, because it violates Apple's SDK conditions:
>    -Christian
> 
> 

-- 
View this message in context: http://www.nabble.com/Pipmak-for-iPhone-and-or-PSP-tp21617842p21635816.html
Sent from the pipmak-devel mailing list archive at Nabble.com.

Re: Pipmak for iPhone and/or PSP

[Christian W. <cwa...@gm...>]

jcowen wrote:
> how difficult would it be to create a version that runs on the  
> iphone? or perhaps the PSP?

Technically, I'd expect an iPhone port to be feasible, and it's  
actually on the list of things that I'd like to do sometime (that  
doesn't mean I'll get around to it, however). Some adaptations might  
have to be made for the limited resources, e.g. scaling down big  
panoramas, and for the touch UI, but the basic capabilities are all  
there - it has OpenGL, OpenAL, and SDL exists too.

There is, however, a political problem, as Aidan has already  
mentioned: Even if I do port it, I won't be able to publish it as a  
standalone application, because it violates Apple's SDK conditions:

> An Application may not itself install or launch other executable  
> code by any means, including without limitation through the use of a  
> plug-in architecture, calling other frameworks, other APIs or  
> otherwise. No interpreted code may be downloaded and used in an  
> Application except for code that is interpreted and run by Apple's  
> Published APIs and built-in interpreter(s).

It may be possible to publish a whole game made with Pipmak, as long  
as Pipmak is inseparably coupled to it and can't be used to run  
arbitrary content.

I can't say anything about the PSP as I'm not familiar with that system.

   -Christian

Re: [pipmak-devel] Pipmak for iPhone and/or PSP

[Aidan G. <wgs...@ih...>]

jcowen wrote:
> just out of curiousity... I'm not a developer but I've been using Pipmak for
> some teaching of interactive concepts... how difficult would it be to create
> a version that runs on the iphone? or perhaps the PSP?

Christian would probably be able to best answer this, but I have a few things 
to say on this topic.  I seriously doubt that Apple would sign it, because the 
Pipmak engine is completely separate from a Pipmak game, so anyone could use 
the Pipmak binary packaged with a game to run their own game.  Pipmak could be 
modified to run only projects that have been signed by Apple, and this would 
probably not break anything.  And as long as there is a version of SDL for the 
iPhone, I think Pipmak could be ported to the iPhone, but I don't know about 
the PSP.

But Christian is the boss here, so listen to him, not me. ;)

  -Aidan

[pipmak-devel] Pipmak for iPhone and/or PSP

[jcowen <jc...@ma...>]

just out of curiousity... I'm not a developer but I've been using Pipmak for
some teaching of interactive concepts... how difficult would it be to create
a version that runs on the iphone? or perhaps the PSP?

Thanks for any ideas on this...
-- 
View this message in context: http://www.nabble.com/Pipmak-for-iPhone-and-or-PSP-tp21617842p21617842.html
Sent from the pipmak-devel mailing list archive at Nabble.com.

Re: TODO - COPY_PIPMAK_TERMINAL_TO_STDOUT

[Aidan G. <wgs...@ih...>]

Christian Walther wrote:
> Aidan Gauland wrote:
  > Some nitpicky comments about the rest:
> 
> - Checking the argument with lua_isboolean() is not necessary, as  
> every Lua value has a boolean value (nil and false are false,  
> everything else is true). By that check, you're unnecessarily  
> forbidding use of anything but strictly true and false. I don't think  
> it hurts much in this case though, as this function probably isn't  
> ever called with a more complex expression than "true" or "false".
> 
> - For argument checking (assuming that you want to stop Lua execution  
> and not just proceed with a warning), it's better to use the auxiliary  
> functions that call lua_error() than just printing a message to the  
> terminal, such as luaL_error(), luaL_typerror(), luaL_checknumber()  
> etc. (they're not documented, but their source in lauxlib.c is simple  
> enough), so that the user gets an indication of where in their code  
> the error happens.

I agree with you on both points.  I didn't know Lua had those error reporting 
functions.

> - I personally would have used something more human-readable than  
> "PmkTerm" to mark the output. (What the heck is a "Pmk"? :) )
> 
>>  And does anyone else want Pipmak's error messages to go to stderr  
>> as well?
>> I'm still thinking of an easy to make Pipmak do this.
> 
> What exactly do you mean by error messages? Those that go through  
> errorMessage()? They generally mean that Pipmak doesn't run at all,  
> and since Pipmak runs for me, I never see them anyway. Those on the  
> terminal? We already have them on stdout, thanks to your addition. And  
> since Pipmak isn't a noninteractive tool that I call in a shell script  
> or something, I see no need to differentiate between stdout and  
> stderr. So, no, I personally don't.

Hmmm, good point.  I didn't think about Pipmak not being a non-interactive 
program.

Re: TODO - COPY_PIPMAK_TERMINAL_TO_STDOUT

[Christian W. <cwa...@gm...>]

Aidan Gauland wrote:
>  I've addressed the To Do item "Add a way to enable the
> COPY_PIPMAK_TERMINAL_TO_STDOUT flag at run time", and committed my  
> changes
> (which add to the Pipmak reference).

Cool, thanks!

>  But it would good to have somebody else
> (I'm looking at you Christian ;) ) look at the documentation, to  
> make sure
> that someone other than the programmer who made the changes can  
> understand them.

Looks fine to me (but then I'm a programmer too). Personally I  
wouldn't have seen a need to mention the internal variable name  
(CpyTermToStdout), but I guess it doesn't do any harm.

Some nitpicky comments about the rest:

- Checking the argument with lua_isboolean() is not necessary, as  
every Lua value has a boolean value (nil and false are false,  
everything else is true). By that check, you're unnecessarily  
forbidding use of anything but strictly true and false. I don't think  
it hurts much in this case though, as this function probably isn't  
ever called with a more complex expression than "true" or "false".

- For argument checking (assuming that you want to stop Lua execution  
and not just proceed with a warning), it's better to use the auxiliary  
functions that call lua_error() than just printing a message to the  
terminal, such as luaL_error(), luaL_typerror(), luaL_checknumber()  
etc. (they're not documented, but their source in lauxlib.c is simple  
enough), so that the user gets an indication of where in their code  
the error happens.

- I personally would have used something more human-readable than  
"PmkTerm" to mark the output. (What the heck is a "Pmk"? :) )

>  And does anyone else want Pipmak's error messages to go to stderr  
> as well?
> I'm still thinking of an easy to make Pipmak do this.

What exactly do you mean by error messages? Those that go through  
errorMessage()? They generally mean that Pipmak doesn't run at all,  
and since Pipmak runs for me, I never see them anyway. Those on the  
terminal? We already have them on stdout, thanks to your addition. And  
since Pipmak isn't a noninteractive tool that I call in a shell script  
or something, I see no need to differentiate between stdout and  
stderr. So, no, I personally don't.

   -Christian

TODO - COPY_PIPMAK_TERMINAL_TO_STDOUT

[Aidan G. <wgs...@ih...>]

Hello,

  I've addressed the To Do item "Add a way to enable the
COPY_PIPMAK_TERMINAL_TO_STDOUT flag at run time", and committed my changes
(which add to the Pipmak reference).  But it would good to have somebody else
(I'm looking at you Christian ;) ) look at the documentation, to make sure
that someone other than the programmer who made the changes can understand them.

  And does anyone else want Pipmak's error messages to go to stderr as well?
I'm still thinking of an easy to make Pipmak do this.

  -Aidan

Re: Would like to make a small addition to Pipmak

[Christian W. <cwa...@gm...>]

rivenwanderer wrote:
> http://www.nabble.com/file/p20287577/defaults.lua defaults.lua 
> OK, that was easier than I'd expected!  I've uploaded my implementation
> (assuming the Nabble interface does what I want).  The tabs may be wrong,
> and the nesting of if blocks is a bit messy, but it works :)

Cool, thanks for the contribution!

> I discovered that if you specify a handle with a negative azimuth, it draws
> properly when you show handles with "C", but the negative portion does not
> recognize your clicks to transfer you to the target node.  So I added a
> check to make sure that my center-referenced coordinates are always
> converted to positive azimuths (maybe this should be done for all azimuths?
> or should other work be done so that the click is recognized?)

Good point, I fixed this in revision 212 
<http://pipmak.svn.sourceforge.net/viewvc/pipmak?view=rev&revision=212>. 
Your suggestion is good - wrapping the left edge of the handle into the 
range [0, 360) at creation time is more efficient than checking it 
modulo 360 in the hit test function.

> I'd obviously like to see center-referenced handles make it into the
> official release at some point

Certainly - your change is in as revision 213 and will be included in 
the next release. I made one small change (besides fixing the 
indentation and adding documentation): assigning to handle.az is not 
necessary in the panoramic case, Pipmak only ever uses handle.x (and 
dito for el/y).

> but I saw that the
> pipmak_internal.handle(handle) function can be overridden by defining it in
> my own project's main.lua, which makes me happy :)

Well, yeah, but that's a bit hacky. Projects are not supposed to use 
pipmak_internal (that's why it's called internal) and its contents may 
change in arbitrary ways between releases, breaking your project.

  -Christian

Re: [Pipmak-Devel] [pipmak-devel] Would like to make a small addition to Pipmak

[rivenwanderer <riv...@ya...>]

http://www.nabble.com/file/p20287577/defaults.lua defaults.lua 
OK, that was easier than I'd expected!  I've uploaded my implementation
(assuming the Nabble interface does what I want).  The tabs may be wrong,
and the nesting of if blocks is a bit messy, but it works :)

I discovered that if you specify a handle with a negative azimuth, it draws
properly when you show handles with "C", but the negative portion does not
recognize your clicks to transfer you to the target node.  So I added a
check to make sure that my center-referenced coordinates are always
converted to positive azimuths (maybe this should be done for all azimuths?
or should other work be done so that the click is recognized?)

I'd obviously like to see center-referenced handles make it into the
official release at some point--but I saw that the
pipmak_internal.handle(handle) function can be overridden by defining it in
my own project's main.lua, which makes me happy :)

Thanks for the help so far!
-- 
View this message in context: http://www.nabble.com/Would-like-to-make-a-small-addition-to-Pipmak-tp20269828p20287577.html
Sent from the pipmak-devel mailing list archive at Nabble.com.

Re: [Pipmak-Devel] Would like to make a small addition to Pipmak

[Christian W. <cwa...@gm...>]

Hi rivenwanderer

I was just writing my reply to your e-mail (sorry for the delay, busy 
days at work) and was about to suggest moving such discussion to the 
mailing lists. I see you found them on your own - welcome.

rivenwanderer wrote:
> I'm not that familiar with Pipmak's source code, nor with Lua in general. 
> However, I'd like to add the option to specify handle locations in terms of the
> center of the rectangle (with perhaps parameters name [caz, cel] or something
> similar).  Internally, this could hopefully just be mapped back to the regular
> representation (az=caz-w/2, el=cel+h/2) in a seamless way so that the rest of
> the treatment of handles would be unaffected.

Sounds like a good idea - and it's even something you can add without 
having to recompile Pipmak.

I agree with your suggestion, caz/cel would just override az/el when 
specified. For flat nodes, I'd add cx/cy that override x/y.

> Can anyone point me at the portion of the source where this could be
> accomplished?

Short answer: defaults.lua, function pipmak_internal.handle(handle) 
(line 521 in my development version). The defaults.lua file is at 
resources/resources/defaults.lua in the source code (if you want to 
compile from source), in 
Pipmak.app/Contents/Resources/resources/defaults.lua on Mac OS, or at 
resources/defaults.lua in the file "Pipmak Resources", which is a ZIP 
archive, on Windows and Linux.

Long answer: Pipmak can be divided into a "Lua side" and a "C side". 
Reading project Lua files obviously belongs to the Lua side, but the Lua 
side extends futher into Pipmak's innards in that things that Lua is 
good at, like handling of dynamic lists, strings, and tables, are done 
in Lua. The Lua side is entirely implemented in the mentioned 
defaults.lua file (that you can modify in a released binary version, 
without having to compile the C side or even needing an SVN checkout or 
a source release). All the rest, like the whole rendering and event 
handling, is done in C. The interface between the Lua side and the C 
side consists of functions callable from Lua but implemented in C, 
mostly in file pipmakLuaLib.c, and C objects (structs) wrapped as Lua 
"userdata" objects (images and sounds are examples of such objects). 
Other objects have representations on both the Lua side and the C side, 
such as nodes. The Lua representation (that the project author interacts 
with) in that case is an ordinary Lua table, with a metatable assigned 
that gives the object its methods. Projects are supposed to treat these 
tables as opaque objects, only using their methods or pipmak functions 
to interact with them, but the contents of the table are plainly 
accessible for those who want to take a look. The C representation of 
the object is a C struct that is never directly touched by the project's 
Lua code. The two representations refer to each other, and each only 
contains as much information as the respective side needs (they largely 
overlap, but neither is a subset of the other).

Handles, in particular, are handled entirely on the Lua side, they have 
no C representation (hit testing is done by event handling branching out 
from the C side to the Lua side by calling function 
pipmak_internal.getcontrol_flat() or ..._pano()). Their Lua 
representation, incidentally, is directly the table a node.lua file uses 
to describe the handle, and the "handle" function that interprets it 
mostly consists of argument validation (and conversion of the simplified 
"target/effect" syntax for navigation controls to the generic syntax). 
Recall that a node.lua statement like "handle { target = 15 }", while 
conceptually a declarative statement, is technically a Lua function call 
- function "handle" is called with a new table (that maps the string 
"target" to the number 15) as a single argument. There is no parser for 
node.lua syntax built into Pipmak, reading a node.lua file means running 
it. That's the powerful concept that makes it effortless (from the point 
of view of me, the Pipmak developer) to support things like making the 
image of a patch not constant, but dependent on game state (or even much 
more complex things like Andrea's Autocubic system).

Loading a node from a node.lua file works roughly as follows: On the C 
side, the C representation of the node object is created and a few of 
its most important fields are filled in. Then the Lua representation is 
created (still on the C side, by Lua C API calls), the two 
representations are cross-referenced, and then handed over to the Lua 
side by calling function pipmak_internal.loadnode() (defined in 
defaults.lua). That function initializes more fields in the Lua table 
representation of the node object and then executes node.lua. Node.lua 
calls back to functions like "handle". These functions are only assigned 
to these short names during execution of node.lua and unassigned 
afterwards (to stop people from trying to call them at other times than 
node loading, which would make a mess). Their permanent definitions live 
under the same names in the pipmak_internal table, i.e. 
pipmak_internal.handle() etc. These functions fill more values into the 
Lua representation of the node object. When control returns from the Lua 
side to the C side after the end of pipmak_internal.loadnode(), the C 
representation of the node is fully initialized by reading out some of 
the contents of the Lua representation and storing them in the C struct.

(Disclaimer: This is all written mostly from memory and may contain 
small inaccuracies.)

> In general, is there any documentation of the overall structure of Pipmak's architecture?

There isn't, as far as I'm aware. I hope what I wrote above helps to 
some extent. You're welcome to put it onto the wiki and augment it by 
your own observations. If you have more questions, please come back and 
ask. I can show you an implementation of your proposed "handle center" 
feature if you like, that's a matter of a few minutes, but maybe you 
want to have a try yourself first.

When you examine pipmak_internal.handle(), there's one potentially 
confusing expression that jumps at me right now: the line "if 
math.mod(node.type, 2) == 1" should be read as "if this node is flat". 
It has historically happened that the node types for flat nodes (slides, 
  panels) are odd, while panoramic node types (cubic, equirectangular) 
are even (equirectangular is currently only used for hotspot maps, not 
for nodes).

  -Christian

[Pipmak-Devel] Would like to make a small addition to Pipmak

[rivenwanderer <riv...@ya...>]

I'm not that familiar with Pipmak's source code, nor with Lua in general. 
However, I'd like to add the option to specify handle locations in terms of the
center of the rectangle (with perhaps parameters name [caz, cel] or something
similar).  Internally, this could hopefully just be mapped back to the regular
representation (az=caz-w/2, el=cel+h/2) in a seamless way so that the rest of
the treatment of handles would be unaffected.

Can anyone point me at the portion of the source where this could be
accomplished?  In general, is there any documentation of the overall structure
of Pipmak's architecture?

Thanks!
-rivenwanderer

Re: [Pipmak-Devel] Named nodes - request for testing

[Andrea V. <and...@gm...>]

Yes, 

You are right, if we want to maintain compatibility with old project, this 
is the only (or simplest) way, I have understand.
I have read the doc very quickly...

I think the better way to doesn't make confusion is to use absolute paths,
and use relatives one for modules...
 
Now r211 seems ready to add modules...

Ok for rotation naming too.

Bye 

Andrea

Re: [Pipmak-Devel] rotation order string

[Christian W. <cwa...@gm...>]

Andrea Viarengo wrote:
> about rotation order, the string to use is "xyz", but z doesn't mean
> rotation around axys Z, but it means rotation around an axis pointing inward,
> I think this could generate confusion...what do you think?
> (using "xya" instead?)

It's true that z doesn't mean the global z axis, but neither does x mean 
the global x axis nor y the global y axis. In my opinion, "xya" is more 
confusing than "xyz". If anything, we should change all of them, 
including the "anglex" and "angley" properties, and I'd rather not do 
that because the latter are already out in a released version.

The reason that "angle" is not called "anglez" is that it's already 
useful for normal 2D patches, and is the only meaningful angle there, 
while "anglex" and "angley" are part of the "advanced" 3D positioning 
syntax. Being user-friendly in the basic case justifies the 
inconsistency for the advanced case here in my opinion.

  -Christian

Re: [Pipmak-Devel] Named nodes - request for testing

[Christian W. <cwa...@gm...>]

Andrea Viarengo wrote:

> When I start the project, I enter in node
> 
> first/second: Ok
> 
> But now if I press "ESC", I get the error:
> 
> Error loading lua file "first/0/node.lua": file not found.

Good catch - this is fixed in r210, thanks.

> If I have this structure:
> 
> 1) ...first/node.lua
> 2) ...first/second/node.lua
> 3) ...second/node.lua
> 
> a) pipmak.gotonode("first")  --now I am in (1)
> b) pipmak.gotonode("second") --now I an in (3) not in (2)
> c) pipmak.gotonode("first/second") --now I an in (2)
> 
> Is it correct this behaviour? Because it's different from 
> navigate into filesystem (I am expect to go into (2) with (b)

This is correct. This behavior is necessary for backwards compatibility 
with projects that assume the old "flat" project structure. Or can you 
think of a way of retaining backwards compatibility without this 
exception (or worse exceptions)?

Is the note about this in the manual not clear enough? Or did you just 
not read the manual (for which I wouldn't blame you, it's normal that 
people don't read the manual, and if we can somehow be fault-tolerant in 
this respect, all the better)?

Besides, apart from the fundamental disadvantage of being an exception 
in the first place, I think this exception actually makes things easier 
in the case that many (or all) nodes are in the same folder, which I 
assume will be the usual case: it allows you to write 
pipmak.gotonode("othernode") instead of pipmak.gotonode("../othernode").

> d) pipmak.gotonode("../")   -- should it be possible? (doesn't work)
> Error loading lua file "node.lua": file not found.

This should be possible (for the sake of completeness, if nothing else - 
I'm not sure if it makes any real sense to have the root of the project 
be a node itself). By "doesn't work", do you mean that there's a bug 
here, in your opinion? In my opinion, this error message is correct, you 
can't go to a node that doesn't have a node.lua (i.e. by definition 
isn't a node).

> Now we put a node.lua in the same folder of main.lua
> 
> e) pipmak.gotonode("/")   --it's works!
> if I press "n" I get "We're at node" (without anymore)

OK, that last part is confusing. I added quotation marks around the node 
name in r210, so even an empty node name comes out recognizably.

> Now, delete node.lua in the same folder of main.lua
> (I use command line to run lua)
> h) pipmak.gotonode("/first/second")  --ok
> i) pipmak.gotonode("../")  --error (not found)
> press "n" --> We are at node -11
> l) pipmak.gotonode("/second")  
> Now I get:
> error running text editor handler:
> -11/node.lua:76 calling selection on bad self.......

Whew. What happens is that after the failed loading of node "/", there's 
no background node anymore because the old node has been left already, 
so the Lua command line overlay drops down into the background node 
slot. Therefore, when you call gotonode(), that node is left, and since 
the Lua command line code isn't prepared for having its node taken away 
from under it, you get the error message in the end.

This is clearly not good. In r211, I've changed the node loading 
sequence so that the old node is only left after the new node has been 
loaded successfully (entering the new node still only happens 
afterward). When there are errors loading the new node, the old node is 
not left but stays, avoiding the overlay-becoming-background. Hope this 
works better.

Thanks for the meticulous testing!

  -Christian

[Pipmak-Devel] rotation order string

[Andrea V. <and...@gm...>]

Hi, 

about rotation order, the string to use is "xyz", but z doesn't mean
rotation around axys Z, but it means rotation around an axis pointing inward,
I think this could generate confusion...what do you think?
(using "xya" instead?)

Bye.

Andrea

Re: [Pipmak-Devel] Named nodes - request for testing

[Andrea V. <and...@gm...>]

Hi, 

Good and bad news:

r209 works fine with old project (autocubic and forest gen. also),
but it have had little problems with a new one:

New project:

named-test.pipmak/main.lua
named-test.pipmak/first
named-test.pipmak/first/second
named-test.pipmak/first/second/node.lua
named-test.pipmak/first/second/face.png

main.lua:
-------------------------------------------
version (0.27)

title "named-test"
startnode ("first/second")
-------------------------------------------

node.lua:
-------------------------------------------
cubic {
	"face.png", --front
	"face.png", --right
	"face.png", --back
	"face.png", --left
	"face.png", --top
	"face.png" --bottom
}
-------------------------------------------


When I start the project, I enter in node

first/second: Ok

But now if I press "ESC", I get the error:

Error loading lua file "first/0/node.lua": file not found.

This error doesn't happen if I use only one level folder
(i.e.: startnode ("second") and I moved "second" out of "first")

If I have this structure:

1) ...first/node.lua
2) ...first/second/node.lua
3) ...second/node.lua

a) pipmak.gotonode("first")  --now I am in (1)
b) pipmak.gotonode("second") --now I an in (3) not in (2)
c) pipmak.gotonode("first/second") --now I an in (2)

Is it correct this behaviour? Because it's different from 
navigate into filesystem (I am expect to go into (2) with (b)

d) pipmak.gotonode("../")   -- should it be possible? (doesn't work)
Error loading lua file "node.lua": file not found.

Now we put a node.lua in the same folder of main.lua

e) pipmak.gotonode("/")   --it's works!
if I press "n" I get "We're at node" (without anymore)  

f) pipmak.gotonode("/first/second") --ok
g) pipmak.gotonode("../")    --now it's work, but I am in "/" 
                               and not in "/first" 

Now, delete node.lua in the same folder of main.lua
(I use command line to run lua)
h) pipmak.gotonode("/first/second")  --ok
i) pipmak.gotonode("../")  --error (not found)
press "n" --> We are at node -11
l) pipmak.gotonode("/second")  
Now I get:
error running text editor handler:
-11/node.lua:76 calling selection on bad self.......

I hope this help you

Bye,

Andrea

 




  



 
 

Re: [Pipmak-Devel] Named nodes - request for testing

[Aidan G. <wgs...@ih...>]

Works just the same for me.  I'll start changing my project to make use of 
this feature.  This should make things much clearer (Lua code in particular).

  -Aidan

Christian Walther wrote:
> I just committed support for named nodes as revision 209. This is quite 
> an invasive change, but if I made no mistakes, it should be backwards 
> compatible with existing projects, unless they do weird things like 
> relying on node:getid() returning a number (it's a string now) or using 
> "../" in paths in different places than once at the beginning (its 
> semantics have changed, it's a real "up one level" command now).
> 
> Therefore, I'd appreciate if those who are set up for building from SVN 
> could check this out and run it through its paces with their projects, 
> to see if I broke anything. Updated documentation is available at 
> <http://pipmak.sourceforge.net/Reference.pdf>, to see what's changed 
> refer to 
> <http://pipmak.svn.sourceforge.net/viewvc/pipmak/trunk/pipmak/documentation/Reference.tex?r1=209&r2=208&pathrev=209>.
> 
>   -Christian

Re: [Pipmak-Devel] Named nodes - request for testing

[Aidan G. <wgs...@ih...>]

Works just the same for me.  I'll start changing my project to make use of 
this feature.  This should make things much clearer (Lua code in particular).

Christian Walther wrote:
> I just committed support for named nodes as revision 209. This is quite 
> an invasive change, but if I made no mistakes, it should be backwards 
> compatible with existing projects, unless they do weird things like 
> relying on node:getid() returning a number (it's a string now) or using 
> "../" in paths in different places than once at the beginning (its 
> semantics have changed, it's a real "up one level" command now).
> 
> Therefore, I'd appreciate if those who are set up for building from SVN 
> could check this out and run it through its paces with their projects, 
> to see if I broke anything. Updated documentation is available at 
> <http://pipmak.sourceforge.net/Reference.pdf>, to see what's changed 
> refer to 
> <http://pipmak.svn.sourceforge.net/viewvc/pipmak/trunk/pipmak/documentation/Reference.tex?r1=209&r2=208&pathrev=209>.
> 
>   -Christian

[Pipmak-Devel] Named nodes - request for testing

[Christian W. <cwa...@gm...>]

I just committed support for named nodes as revision 209. This is quite 
an invasive change, but if I made no mistakes, it should be backwards 
compatible with existing projects, unless they do weird things like 
relying on node:getid() returning a number (it's a string now) or using 
"../" in paths in different places than once at the beginning (its 
semantics have changed, it's a real "up one level" command now).

Therefore, I'd appreciate if those who are set up for building from SVN 
could check this out and run it through its paces with their projects, 
to see if I broke anything. Updated documentation is available at 
<http://pipmak.sourceforge.net/Reference.pdf>, to see what's changed 
refer to 
<http://pipmak.svn.sourceforge.net/viewvc/pipmak/trunk/pipmak/documentation/Reference.tex?r1=209&r2=208&pathrev=209>.

  -Christian