little info on branches
Toni Alatalo
just a little information about the branches where quite substantial
work is going on in different places. just for the devs to know,
possibly doesn't require any coordination (are quite orthogonal, even
though there is overlap is is probably quite simple and small):
a) Enne's develop_withtundra updates: a candidate for a future unified
branch, which merges tundra to develop so a separate tundra branch isn't
needed anymore (except perhaps as a light build preconfig). Continues on
the merges Jukka and I did earlier. Has text-to-speech etc. which came
to develop after tundra merged from there the last time. Is currently
AFAIK Tundra 1.0.4, but pulling current tundra to this should go pretty
smoothly. Alberto said IIRC a couple of weeks ago that they'll be
merging their other dev branches and updating their main repo, when have
the time. Has separated the av&world cards using login to an own module
(out of UiModule) etc. Ah and has the configurable QtScript debugger
integration, https://github.com/enne/naali/tree/develop_withtundra4
b) Chiru is working on multiconnection / multiscene support. Very much
work in progress, I don't know if the code that actually uses it is on
github yet even. Had fun bugs >week ago when they showed the
work-in-progress, when there was multiple tundra connections and
scenemanagers but still only a single underlying ogre scene :)
https://github.com/Chiru/naali/tree/perscene-syncmanager
c) Jukka began a very interesting aggressive refactor branch, a 'fix
everything' effort it seems :) (sounded that because he was ill so had
time of from project work :p) .. cuts down dependencies (Poco is gone,
module loading done somehow simply in own code, there are no module xmls
anymore etc), removes useless namespaces and does js exposing more
cleverly etc. Jonne was making a new config api here yesterday (for fun)
etc., https://github.com/realXtend/naali/commits/tundrajj . Jukka
himself said that he doesn't yet know what the future of that branch is,
but at least a fun experiment I figure .. to see how small and simple we
can go. The simpler the better, I figure -- some other players/viewers
like Unity3d, Panda3d and Gamekit are ~5-15MB downloads and start
quickly, that's a good target for our core too. All the functionality of
the current develop / Naali 0.4.0 >100MB download monster can still
remain as optional. But certainly we don't always want to be like an
operating system distribution, with not only qt, but also half of
gtk/gnome (for telepathy dbus things) and the python standard library
included :)
I won't be touching these much soon, but try to stay on track of what's
going on .. while working on demos etc. (LVM has an infinite todo, and
much basics missing, but I got bored of not being able to run the
project visualization thing so tested as my free time fun porting it
from opensim to tundra .. i see lego bricks already :) The code is in
https://github.com/antont/rexprojectspace/ .. the 3rd party blog post
about it is this in google cache
http://webcache.googleusercontent.com/search?q=cache:FL1MnE4qLycJ:blog.knowsense.co.uk/blog/_archives/2010/12/20/4707937.html+opensim+software+project+alatalo&cd=4&hl=fi&ct=clnk&gl=fi&source=www.google.fi
the original address says now that the blog has used all it's
bandwidth :p
http://blog.knowsense.co.uk/blog/_archives/2010/12/20/4707937.html
After demos are in better shape, I can probably return to help with
merge work and other core things .. for example in May after LVM has
been published.
~Toni
Andres Navarro
As commented before, here at Enne we have continued developing on
several topics and a new version has been uploaded to
https://github.com/enne/naali/tree/develop_withtundra4.
Main changes are the development of a new Camera Module to add new
widgets showing different perspectives of the selected object,
improvements on the UiModule and EtherModule, fix of the object
manipulators, corrections on the javascript debugging and merging of
Tundra 1.0.5 version. More detailed description of the changes is
below and if it is desired we could create an entry on the realxtend
wiki to explain the use of the cameras.
We will appreciate any comments about the presented functionality and
being the tundra 1.0.5 version merged, we would encourage the
community to agree on having a single development branch.
We will present on another post following development topics we are
going to work on at Enne, although development will be slowed down on
next two weeks because of Easter holiday.
Best regards,
Andrés Navarro
ENNE
Entertainment
Studios
The new CameraModule provides:
* New action on menu->Views (“New Camera View”) to create first
widget
* For each camera widget:
o Projection type: perspective or orthographic
o Camera type: pivot, front, back, left, right, top or
bottom.
o Wireframe renderer enabled or not
o Create new camera widget
o Delete camera widget
o Move near and clip distance using buttons or modifies:
o Ctrl + wheel: move near clip distance
o Ctrl + Shift + wheel: move far clip distance
* When new object is selected from renderer window all cameras are
centered to that object. The camera position and clip distances
depends on object size.
* When camera widget is hidden the widget is destroyed. That
happens when you change to a new configuration of the widgets.
* In order to develop this module we have added a new method
“GetRawTexture” to EC_RttTarget component to get camera texture in
raw format.
Changes on the UiModule:
* Notifications are available at the UiService interface.
* Extend AddInternalWidgetToScene with persistence, to keep or not
widgets between worlds.
* Views updated with "last view not saved" option to go back to
the last view selected when changing to a different view
* UiService extended with submenus
* Menu actions of the QMainWindow have the checkable component to
see if it's widget is shown or hidden
* UiSettings architecture updated (one group for one widget).
Note: It is neccesary to delete the previous settings file before
first use to make them work properly.
* UiExternalModule code removed.
At the EtherModule:
* EtherModule connected with TundraLogicModule events.
* Allow to disconnect, reconnect and exit from the EtherModule.
* Display information about the connection state.
* Perform player screenshot at Tundra worlds.
Object tools Manipulators:
* Make use of EC_Placeable transform attribute.
* Show scale with object rotation
* Allow multiple objects rotation in every axis.
* Fix edit object widget
Javascript Debugger:
* Allow debugging after first script evaluation: slots, actions...
* Fix errors when disabling debugging and shutting down
application.
Some other fixes and small changes
* PlayExclusiveAnim() added to be callable from javascript scripts
* knet satistics window added to main window when uiService is
available
* Tts module updated and cleaned
On Apr 11, 10:34 am, Toni Alatalo <t...@playsign.net> wrote:
> hi,
>
> just a little information about the branches where quite substantial
> work is going on in different places. just for the devs to know,
> possibly doesn't require any coordination (are quite orthogonal, even
> though there is overlap is is probably quite simple and small):
>
> a) Enne's develop_withtundra updates: a candidate for a future unified
> branch, which merges tundra to develop so a separate tundra branch isn't
> needed anymore (except perhaps as a light build preconfig). Continues on
> the merges Jukka and I did earlier. Has text-to-speech etc. which came
> to develop after tundra merged from there the last time. Is currently
> AFAIK Tundra 1.0.4, but pulling current tundra to this should go pretty
> smoothly. Alberto said IIRC a couple of weeks ago that they'll be
> merging their other dev branches and updating their main repo, when have
> the time. Has separated the av&world cards using login to an own module
> (out of UiModule) etc. Ah and has the configurable QtScript debugger
> b) Chiru is working on multiconnection / multiscene support. Very much
> work in progress, I don't know if the code that actually uses it is on
> github yet even. Had fun bugs >week ago when they showed the
> work-in-progress, when there was multiple tundra connections and
> c) Jukka began a very interesting aggressive refactor branch, a 'fix
> everything' effort it seems :) (sounded that because he was ill so had
> time of from project work :p) .. cuts down dependencies (Poco is gone,
> module loading done somehow simply in own code, there are no module xmls
> anymore etc), removes useless namespaces and does js exposing more
> cleverly etc. Jonne was making a new config api here yesterday (for fun)
> but at least a fun experiment I figure .. to see how small and simple we
> can go. The simpler the better, I figure -- some other players/viewers
> like Unity3d, Panda3d and Gamekit are ~5-15MB downloads and start
> quickly, that's a good target for our core too. All the functionality of
> the current develop / Naali 0.4.0 >100MB download monster can still
> remain as optional. But certainly we don't always want to be like an
> operating system distribution, with not only qt, but also half of
> gtk/gnome (for telepathy dbus things) and the python standard library
> included :)
>
> I won't be touching these much soon, but try to stay on track of what's
> going on .. while working on demos etc. (LVM has an infinite todo, and
> much basics missing, but I got bored of not being able to run the
> project visualization thing so tested as my free time fun porting it
> about it is this in google cachehttp://webcache.googleusercontent.com/search?q=cache:FL1MnE4qLycJ:blo...
> the original address says now that the blog has used all it's
Toni Alatalo
> several topics and a new version has been uploaded to
> https://github.com/enne/naali/tree/develop_withtundra4.
Hi again!
I failed to test earlier, was getting a linking error due to Scene lib missing, and only a couple of days ago realized that it was just because I had an old CMakeBuild.txt lying around there (realized 'cause got a similar problem with mainline tundra branch when Devices API was added).
Now there is the problem that knet has changed since 1.0.5, and that branch is still at that, so a question:
Are you planning to merge again, bring tundra 1.0.7 (tagged yesterday) to this version of develop?
If not, I could test it anyhow by building with 1.0.5 compatible knet, or try cherry-picking the knet related commits since 1.0.5 to develop_withtundra (may be easy).
> Main changes are the development of a new Camera Module to add new
> widgets showing different perspectives of the selected object,
> improvements on the UiModule and EtherModule, fix of the object
> manipulators, corrections on the javascript debugging and merging of
Would like to get to test these nice new feats, cam module sounds like a great addition for editing (i suppose that's why you added it too). Fixed obj manipulators and JS debugging certainly too.
BTW I suppose you have some sort of windows builds of this version for your own version? That would help to test too.
> being the tundra 1.0.5 version merged, we would encourage the
> community to agree on having a single development branch.
Yep getting rid of unnecessary divides would be good indeed.
> Andrés Navarro
~Toni
> --
> http://groups.google.com/group/realxtend-dev
> http://wiki.realxtend.org
> http://dev.realxtend.org
Andres Navarro
On May 20, 12:10 pm, Toni Alatalo <t...@playsign.net> wrote:
> On Apr 14, 2011, at 5:30 PM, Andres Navarro wrote:
>
> > several topics and a new version has been uploaded to
> >https://github.com/enne/naali/tree/develop_withtundra4.
>
> Hi again!
>
> I failed to test earlier, was getting a linking error due to Scene lib missing, and only a couple of days ago realized that it was just because I had an old CMakeBuild.txt lying around there (realized 'cause got a similar problem with mainline tundra branch when Devices API was added).
>
> Now there is the problem that knet has changed since 1.0.5, and that branch is still at that, so a question:
>
> Are you planning to merge again, bring tundra 1.0.7 (tagged yesterday) to this version of develop?
>
and major problems would be at the Ui. That's a functionality where we
have focused big part of our development (docking interface, multiple
windows configuration, menu ordering and anchored positioning of
widgets) and considering it very useful, we would like to transfer it
to the tundra community development.
Since the refactor of UiService onto UiAPI does not allow having
different implementations of the Ui, which it was always a source of
problems, we propose to start a discussion about the desired behaviour
of the Ui in order to define a clean and simple interface.
Knowing that the community agrees on that interface and that the
result of the merge would be the common base where we could all
continue developing, we would be more than willing to perform it.
> If not, I could test it anyhow by building with 1.0.5 compatible knet, or try cherry-picking the knet related commits since 1.0.5 to develop_withtundra (may be easy).
>
> > Main changes are the development of a new Camera Module to add new
> > widgets showing different perspectives of the selected object,
> > improvements on the UiModule and EtherModule, fix of the object
> > manipulators, corrections on the javascript debugging and merging of
>
> Would like to get to test these nice new feats, cam module sounds like a great addition for editing (i suppose that's why you added it too). Fixed obj manipulators and JS debugging certainly too.
>
> BTW I suppose you have some sort of windows builds of this version for your own version? That would help to test too.
with the following topics we have been working on:
* Extend exposition of Vector3df and Quaternion to Javascript.
* Integration of Javascript BDD framework Jasmine with tests for
Vector3df and Quaternion.
* Extend EC_Placeable methods for relative and absolute rotations.
* AutoSave python component for backing up and restoring scene.
* Ordering of menu entries and several fixes on Ui.
* Fix messages and screenshots on the EtherModule.
Using those changes, we have developed Javascript controllers for
EC_Placeable and EC_RigidBody based entities, which allow easy
rotation and movement and provide several lookAt and goTo methods.
Those controllers have been used to create an avatar script which
allows flying keeping physics and walking based on mouse interaction
with objects.
This development have been performed on a different repository and if
there is anyone interested on the controllers or the avatar
implementations we could upload it to a new repository at github or
add it as a scene to the current source code.
For an easy testing of the functionality, we have uploaded also an
installer for windows (although we have checked that it compiles under
linux): https://github.com/downloads/enne/naali/Tundra-Enne_1.0.5.exe
> > being the tundra 1.0.5 version merged, we would encourage the
> > community to agree on having a single development branch.
>
> Yep getting rid of unnecessary divides would be good indeed.
>
>
>
Let us know any impressions about the changes and the proposal for the
unification process.
Andrés Navarro
ENNE
ENTERTAINMENT
STUDIOS
Jonne Nauha
* Extend exposition of Vector3df and Quaternion to Javascript.
* Integration of Javascript BDD framework Jasmine with tests for
Vector3df and Quaternion.
* Extend EC_Placeable methods for relative and absolute rotations.
* AutoSave python component for backing up and restoring scene.
* Ordering of menu entries and several fixes on Ui.
* Fix messages and screenshots on the EtherModule.
Using those changes, we have developed Javascript controllers for
EC_Placeable and EC_RigidBody based entities, which allow easy
rotation and movement and provide several lookAt and goTo methods.
Those controllers have been used to create an avatar script which
allows flying keeping physics and walking based on mouse interaction
with objects.
Best regards,
Jonne Nauha
Adminotech developer
Andres Navarro
On May 24, 7:27 pm, Jonne Nauha <jo...@adminotech.com> wrote:
> * Extend exposition of Vector3df and Quaternion to Javascript.
> * Integration of Javascript BDD framework Jasmine with tests for
> Vector3df and Quaternion.
> * Extend EC_Placeable methods for relative and absolute rotations.
> * AutoSave python component for backing up and restoring scene.
> * Ordering of menu entries and several fixes on Ui.
> * Fix messages and screenshots on the EtherModule.
> Using those changes, we have developed Javascript controllers for
> EC_Placeable and EC_RigidBody based entities, which allow easy
> rotation and movement and provide several lookAt and goTo methods.
> Those controllers have been used to create an avatar script which
> allows flying keeping physics and walking based on mouse interaction
> with objects.
>
> This part sounds amazing. I'd very much like to see those EC_Placeable and
> EC_RigidBody changes to core. As I struggle with just those same issues many
> time doing js logic. You have to do complex things with vecs and quats in
> js, but then again vector3df does not have many helper funcs in js either,
> and seems you have also fixed/improved that. I think these can be put
> separately without the UI changes to rex/tundra branch?
javascript and it could easily be included on the tundra branch, but
there are at least some changes at JavascriptModule, EC_Placeable and
Quaternion which can't be directly added. However, if the merge gets
heavily delay we could merge these changes isolated.
However, being possible to create widgets, menus and toolbars from C++
modules, python modules or application specific and world specific
javascripts, we believe some helpers should be provided to keep a
clean and usable interface, always allowing a finer control via basic
Qt methods.
The idea of having an extra module which modified the behaviour of the
Ui was used in the past, UiExternalModule modifying UiModule,
generating several problems, being finally agreed to be integrated
into the UiModule. Hence, the signals/slots proposal seems a good idea
for extra functionality (like the different windows configurations)
but we think it cannot be applied to modify content that should be
present whether or not the extra module is loaded. That is the case
for widgets like the SceneStructure, EC editor, Assets, Environment,
Edit tools, Post processing, Console, Python console, Script
debugger... Although we strongly believe that an interface with all
these widgets floating is not easy to use, if docking behaviour is
desired to be a ui customization by a different module, we think a
customization interface should be defined towards the UiAPI should
refer widgets inclusion when an implementation is present.
Another thing we consider that should be addressed in the first place
is the inclusion or not of the possibility of having multiple graphics
scenes, used in the past for the Ether and Avatar scenes. Although
previous implementation wasn't very clean, we think that the existence
of multiple graphics scenes could be very handy if they are associated
with the scene managers, taking into account a future version where
connection with several worlds is allowed. Afterwards, we can discuss
whether or not and how to include anchored widgets functionality which
allows easy inclusion of widgets without worrying about other widgets
position.
About the control of menus, we extended the ui interface with a
priority argument to allow ordering without having to create every
menu entry from a single script. We think the same approach could be
taken on the UiMainWindow, as well as including some methods for
toolbars inclusion.
Best regards,
Toni Alatalo
> linux): https://github.com/downloads/enne/naali/Tundra-Enne_1.0.5.exe
I think this is seriously cool, from an end user perspective -- anyone interested in how creating with Tundra works should try this. Is basically just the same docking biz as in 0.4, but with improvements like being able to save window layouts etc.
We are talking about the technical side on IRC now, I'm sure we can fine a nice way to integrate. A little more of how and why I find these UI additions so useful, and certainly studio Enne has had good reasons to keep that going .. helping creators in being productive is most important in the toolset.
~Toni
14:16 < antont> i was doing the port of that game also to get first hand experience of how creating something with tundra is now
14:17 < AndresENNE> that's a good way to evaluate user experience
14:17 < antont> and hated how was lost with the eceditor & scenestruct windows all the time when switching between those and my code editor etc, and when needed to restart the server constantly always had to again open scenestruct + ecedit etc
14:17 < antont> having this nice layout, basically like the old build mode, would have helped me this morning i think
14:18 < antont> nice how the consoles are there too, i always liked having the console docked with 0.4 .. handy especially when have several e.g. clients open, to stay on track on what console belongs to which client
14:19 < AndresENNE> every widget can be docked or not
14:20 < antont> yep
14:21 < antont> is perfect i think
14:21 < antont> like was in 0.4 already basically
Jonne Nauha
Best Regards,
Jonne Nauha
Adminotech developer
Andres Navarro
On May 31, 3:27 pm, Jonne Nauha <jo...@adminotech.com> wrote:
> Hear hear UI improvements are welcome. I will test it when i get the change. I trust enne can make a proposal on how to merge their work to tundra branch and what changes are required to UiAPI. If the work is done lets try to merge sooner than later before the tundrajj/tundra-lite work kicks to full gear by me/us :) so in a week or so. But i can merge later too ofc, so no rush really to finish it. Would just be nice to get the enne guys working already on the same branch as the rest of us :)
>
> Best Regards,
> Jonne Nauha
> Adminotech developer
>
Indeed, everybody working on the same branch would be great.
Therefore, having discussed a bit the possibilities to perform the
merge, we think the signals and slots idea could be a nice approach
with small changes at the UiAPI. Hence, a proposal for the integration
would be:
For including docking behaviour:
* Extend UiAPI with:
o public slot AddWidgetToWindow(QWidget* widget, const
QStringList ¶ms = QStringList(), Qt::WindowFlags flags =
Qt::Dialog)
o signal CustomizeAddWidgetToWindow(QWidget*, QStringList,
Qt::WindowFlags)
* UiAPI implementation would call QWidget::show() if property
"customized" hasn't been set to QWidget after emitting signal.
* Modify widget creator modules (SceneStructure, ECEditor,
Asset...) to make use of the new slot.
For allowing user custom windows layouts:
* Extend UiAPI with:
o public slot EmitCreateDynamicWidget(QString, QString,
QVariantList)
o signal CreateDynamicWidget(QString, QString, QVariantList)
For allowing ordering of menus and action entries:
* Extend UiMainWindow with:
o QMenu *AddMenu(const QString &name, int priority)
o QAction *AddMenuAction(const QString &menuName, const
QString &actionName, const QIcon &icon = QIcon(), int priority)
For including anchored internal widgets, which are added to and anchor
layout on the QGraphicsScene so there is no need to restore its
position when window is resized:
* Extend UiAPI with:
o public slot AddAnchoredWidgetToScene(QWidget *widget,
Qt::Corner corner, Qt::Orientation orientation, int priority)
Let us know any opinion about this proposal, which being agreed by the
community, we think it won't take to implement more than a week.
Best regards,
Peter Steinlechner
Could this be also de-/activated by an ACL, so it doesn't show if the users has no rights to create/change things?
A question also came up about the possibility if users could temporary load objects to the server (similar to the autoreturn in OpenSim)? I think this could be quite useful for collabortion.
Cheers
Pedro
--
Toni Alatalo
> Could this be also de-/activated by an ACL, so it doesn't show if the
> users has no rights to create/change things?
yes - now it works so that server.exe and viewer.exe load that ui, but
there is also player.exe which doesn't have the authoring tools .. just
a pure end user thing. that's how Enne needs it so they did that, is so
in that build.
> A question also came up about the possibility if users could temporary
> load objects to the server (similar to the autoreturn in OpenSim)? I
> think this could be quite useful for collabortion.
what is autoreturn? you mean like a sandbox is reseted? that's how the
www.realxtend.org demo works now, changes to the scenes there are not
saved.
> Pedro
~Toni
Peter Steinlechner
with autoreturn I mean the feature, that everyone can rez something in SL, but just for a certain time the owner has set to that parcel. I think it can be handy to allow people to test or show something without giving them full rights to clutter up the place :-)
Jonne Nauha
Best regards,
Jonne Nauha
Adminotech developer
Toni Alatalo
> I don't know if we gonna implement this kind of "temp" rezzing into
> the security system. I guess its up to the server side security
> script, hopefully we can get a nice solution so you can implement that
> kind of model on your own :) We will make the tundra changes needed
Yes editing policies, sandbox logics etc. are all very much applications
specific things.
> Toni: Any idea who/when this could be actually started now that we are
> on the security topic. Maybe you could take a look after the game
> stuff you doing now? :)
I can probably work on it after the 9th -- that's when need to demo nice
things, hopefully some first test of that game port a little too :) ..
but also probably integrate knon and some of toy, with the tools, to the
same scene etc .. which must run without remote connections etc.
The only question regarding that permissions hook has been whether we
can do it by changing the existing OnEntityCreated and
OnAttributeChanged signals, or whether we need new ones.
My current understanding is that we need new ones that are emitted
before those. Because with those we can't control the order in which the
go to different handlers, so the perm hook might come after other places
applied the change already. Signals don't have priorities or a filter
mechanism etc.
So unless there are better ideas by the 10th, I can try adding the
hooks .. perhaps BeforeEntityCreated or PreAttributeChanged or something
would be nicer names than AttributeAboutToChange, or at least
EntityAboutToBeCreated? (the current signal for authentication is
server.UserAboutToConnect and there's also server.IsAboutToStart()). I
can do it with ugly names first and see how it works, names are easy to
change then :)
Jukka suggested that the attribute change signals should have both the
old and new values included and that sure seems like a good idea.
> Jonne Nauha
~Toni
Andres Navarro
We have finished merging develop_with_tundra branch with tundra1.0.7
tag. Source code can be found at https://github.com/enne/naali/tree/develop_withtundra107,
as well as a windows installer at https://github.com/downloads/enne/naali/Tundra-Enne_1.0.7.exe
After several discussions via IRC, the following changes were
introduced:
* Extend UiAPI with UiWidget *AddWidgetToWindow(QWidget*,
Qt::WindowFlags, const QStringList):
* New UiWidget class which contains added widget and signals
custom ui modules about visibility status.
* New IUiWidgetFactory interface which allows registration from
modules as widgets constructors as well as UiAPI
RegisterUiWidgetFactory and GetUiWidgetFactory methods.
* Extend UiMainWindow AddMenu and AddMenuAction with priorities to
allow ordering.
* Added getXWidget method on modules with toogleXWidget methods to
allow setting trigger action checked when widget is visible.
* Added getSettingsWidget method on modules with
showSettingsWidget method to allow tabbing settings widgets on a
single one.
Cleanup of custom ui module is still pending but that won't affect
main ui project.
Let us know any comments about the merge.
Best regards,
Andrés Navarro
ENNE
ENTERTAINMENT
STUDIOS
> You can rez whatever you want in our demo worlds via the portal. There is no
> time limit but the content will be lost on the next restart. We provide the
> demo scene now but rex can give us any txml basically and we can make it the
> base for the portal servers. Storing the scenes is in the works too. But we
> need that security update to Tundra, at least protecting the base scene that
> it wont be deleted by users.
>
> I don't know if we gonna implement this kind of "temp" rezzing into the
> security system. I guess its up to the server side security script,
> hopefully we can get a nice solution so you can implement that kind of model
> on your own :) We will make the tundra changes needed for this and provide
> some kind of base security model you can improve on your self depending on
> your needs.
>
Jonne Nauha
Best regards,
Jonne Nauha
Adminotech developer
Andres Navarro
We made some improvements, including Jonne suggestions, as well as
finishing with the UiModule cleanup that we mentioned. Source code can
Hence, minimum size has been adjusted for several widgets, tabbed
widgets don't resize when selecting a different tab, extra space has
been removed, ec editor behaviour restored, and toggling edition,
edition manipulators and edition toolbar fixed.
About changing tabs position on top of the widget, we tried that but
it doesn't look nice because widget name looks duplicated with tab
title and widget title so close. It could be performed by replacing Qt
default tabbed title widget or by adding a make widget floating button
to the tab itself, and it would look nicer adding directly the current
web browser toolbar to the main window.
We have also included a demo scene which contains the scripts
commented on the past that allow easier movement and rotation of
entities with other features like sending and avatar to a position,
keep physics while flying and make an avatar follow a path.
Best regards,
Andrés Navarro
ENNE
ENTERTAINMENT
STUDIOS
Toni Alatalo
> We made some improvements, including Jonne suggestions, as well as
> finishing with the UiModule cleanup that we mentioned. Source code can
> be found at https://github.com/enne/naali/tree/develop_withtundra107 ,
Thanks for info!
I've spent some spare moments during my home day setting up a Linux
build of that, first made some stupid mistakes with git branches so got
delays but seems to be running now .. I'll push the little tweaks that
needed to do when it compiles (so far just QWidget.h -> qwidget.h in
UiWidget.h).
Will review the changes a bit and probably push to the central develop
branch soon, so the bot system will be running linux builds when you&we
make further changes there etc.
> Andrés Navarro
~Toni
Jonne Nauha
Best regards,
Jonne Nauha
Adminotech developer
Andres Navarro
wrote:
> branch soon, so the bot system will be running linux builds when you&we
> make further changes there etc.
On Jun 14, 6:26 pm, Jonne Nauha <jo...@adminotech.com> wrote:
> The dl link is broken in your post, here is a working onehttps://github.com/downloads/enne/naali/Tundra-Enne-1.0.7.2.exe
> Good fixes, it feel alot more natural now. I think with not forcing
> everything to be these kind of docked windows, perhaps nothing in core (!!),
> would be better. I kind of like scene and entity editors in the docs and
> console. But everything dont neet to be like this. The most important thing
> is to give scripts the possibility to add these kind of dock-enabled
> widgets, which is the whole point of tundra to support this kind of thing.
> We can iron out the details what should be like this and what possibly not
> after the merge is done.
affecting the "core". If the module is not loaded, widgets behave as
before.
Moreover, widgets behaviour can be tuned by setting dynamic parameters
or using the string list argument of the UiAPI::AddWidgetToWindow
method. For example, with the current uimodule, docking can be
disabled for an specific widget by setting parameter "docking" to
"false".
Hence, any widget added from a script could be configured as desired.
Widgets created on modules are currently added to the window on their
initialization and their visibility is handled from the scripts. It
would be very easy to return on modules the QWidget and let the
scripts add them to the window being free to set any parameter.
> Good stuff in general. I didnt see what was special in the demo scene (i
> tried the movementcontrol.txml). Just one guy turning automatically there
> when he did a collision with something :)
interface any entity, independently if it contains or not a dynamic
rigid body, can be moved and oriented with the same methods and
actions, allowing: relative move and rotate based on masks and
velocity attributes, movement to a point and rotation towards a point.
Following a path is just an example of how it can be used to move an
avatar or a camera or a kinematic object. I have included the scripts
documentation based on JsDoc which details usage (https://github.com/
enne/naali/tree/develop_withtundra107/bin/scenes/MovementControl/
jsdoc).
Toni Alatalo
> So great to hear. This time we didn't have time to test it on linux.
That one include capitalization fix was the only one needed, compiled
and ran then.
There's one stupid problem: the files you have edited and added (lots of
interesting stuff there, haven't seen much of it yet) seem to have CRLF
line endings now for some reason, the windows/dos style, instead of the
plain LF unix-style which is usually used with Git, and in the Naali
repo too.
I followed the procedure in the github info page to convert them, that
has also info of the settings which should prevent this from happening:
http://help.github.com/line-endings/ .. i.e. set git option autocrlf to
true in your dev machines, please. I'm sorry we didn't give this
instruction earlier, apparently miss a link to it in our wiki even.
Pushed the linefeed conversion and the linux build fix to
https://github.com/antont/naali/commits/dwt107 -- you can either pull
from there, or convert the line endings yourself .. is a bit stupid that
when I made, I'll show as the latest author of the lines you've written,
but the actual history is of course there too so doesn't matter too
much.
The simple bundled examples are working for me, but get a crash
(segfault) when try to load the LVM / Chesepeake Bay app. It is in the
Javascript modules transform attrs conversion func -- apparently you had
some js support changes, but I didn't see what exactly yesterday 'cause
ran into problems with diffing against the mainline version due to the
linefeed differences (every line showed as different :p). This is the
crash:
Program received signal SIGSEGV, Segmentation fault.
fromScriptValueTransform (obj=..., s=...)
at /home/antont/src/enne-naali/JavascriptModule/ScriptCoreTypeDefines.cpp:399
399 s.position = *pos.data();
Apparently you have changed this part, like this? Does LVM
scene2/lvm_full.txml work for you? I haven't had access to windows now
so have only been able to test with this own build.
< fromScriptValueVector3(obj.property("pos"), s.position);
< fromScriptValueVector3(obj.property("rot"), s.rotation);
< fromScriptValueVector3(obj.property("scale"), s.scale);
---
> // $ BEGIN_MOD $
> Vector3dfPtr pos =
qscriptvalue_cast<Vector3dfPtr>(obj.property("pos"));
> Vector3dfPtr rot =
qscriptvalue_cast<Vector3dfPtr>(obj.property("rot"));
> Vector3dfPtr scale =
qscriptvalue_cast<Vector3dfPtr>(obj.property("scale")
);
>
> s.position = *pos.data();
> s.rotation = *rot.data();
> s.scale = *scale.data();
> // $ END_MOD $
I'm travelling this afternoon to Holland, to metameets.com (a demo there
on Saturday) so will be mostly offline till Monday .. back to this more
then.
Cheers,
~Toni
Andres Navarro
Problem at fromScriptValueTransform has been solved and
http://www.realxtend.org/world/lvm/lvm_full.txml scene seems to work.
The updated source code can be found at https://github.com/enne/naali/tree/develop_withtundra107
Only issue remaining at that scene are dynamic rigid bodies. We added
a physics type enum property (static/kinematic/dynamic) to
EC_RigidBody in order to allow kinematic objects which is set to
static by default. Hence, avatars rigid bodies should be set to
dynamic as well as setting their mass.
Best regards,
Andrés Navarro
ENNE
ENTERTAINMENT
STUDIOS
> On Wed, 2011-06-15 at 02:40 -0700, Andres Navarro wrote:
> > So great to hear. This time we didn't have time to test it on linux.
>
> That one include capitalization fix was the only one needed, compiled
> and ran then.
>
> There's one stupid problem: the files you have edited and added (lots of
> interesting stuff there, haven't seen much of it yet) seem to have CRLF
> line endings now for some reason, the windows/dos style, instead of the
> plain LF unix-style which is usually used with Git, and in the Naali
> repo too.
>
> I followed the procedure in the github info page to convert them, that
> instruction earlier, apparently miss a link to it in our wiki even.
>
Toni Alatalo
> Yes editing policies, sandbox logics etc. are all very much applications
> specific things.
> can do it by changing the existing OnEntityCreated and
> OnAttributeChanged signals, or whether we need new ones.
> My current understanding is that we need new ones that are emitted
> before those. Because with those we can't control the order in which the
> go to different handlers, so the perm hook might come after other places
> applied the change already. Signals don't have priorities or a filter
> mechanism etc.
Conclusion is now that new signals are needed, as the way to implement
this kind of a filter mechanism.
We met on Monday with Jukka and Lasse and agreed to go with this set of
signals now -- I'll start implementing when get the chance, perhaps a
first step on coming Monday .. then is a bit unclear with the holidays
etc. This is the plan anyhow:
> hooks .. perhaps BeforeEntityCreated or PreAttributeChanged or something
> would be nicer names than AttributeAboutToChange, or at least
> EntityAboutToBeCreated? (the current signal for authentication is
> server.UserAboutToConnect and there's also server.IsAboutToStart()). I
Jukka had drafted this set of names with AboutTo* style which seems ok:
-Server::UserAboutToConnect (already implemented, works for auth)
-SyncManager::
- AboutToCreateEntity(UserConnection *source, MsgCreateEntity &entity)
- AboutToRemoveEntity(UserConnection *source, MsgRemoveEntity &entity)
- AboutToCreateComponent(UserConnection *source, Entity *target, comp)
* the list of components from net msg split to individual calls
- AboutToRemoveComponent(UserConnection *source, Entity *target, comp)
- AboutToModifyAttribute(UserConnection *source, IAttribute
*targetWithOldValue, QVariant newValue)
* For DynamicComponent:
- AboutToCreateAttribute(UserConnection *source, IComponent *target)
- AboutToRemoveAttribute(UserConnection *source, IComponent *target)
We were also considering a simplification, so e.g. a simple permission
check to disable all editing doesn't need connecting to many signals ..
this would suffice to prevent any remote changes to the scene on server:
- AboutToModifyEntity
* emitted for Create/RemoveComponent and Create/Modify/RemoveAttribute
And for Entity-Actions:
- AboutToTriggerAction(UserConnection *source, Entity *target,
ExecType, QString action, QStringList params)
We actually didn't talk about how to handle the situations when client
makes some change locally, which is then rejected on the server. Was
thinking about it afterwards, and Erno was also wondering yesterday how
to deal with not getting confusing situations with invalid state on the
client.
For the first use case of simply disabling editing on a server, that's
ok, 'cause for such usage in end user applications (such as a game) the
UI probably doesn't have the editing tools (e.g. EC editor) which could
do those changes which would be rejected then. If someone connects to
such a server with a 'rogue' client and tries to edit it, is ok if he
gets confused, as it's not the end user scenario.
But with more fine grained situations where e.g. users can edit their
own objects freely, but not others, or if they can edit some attributes
of some components but not others (e.g. the URLs of webviews) we'll
easily need some info of what's going on to be able to present in the UI
and to keep the state valid on the client.
Have been thinking that one way is simply to do this with custom logic:
e.g. have the permission check module (e.g. a js script) work so that
when it rejects a change on the server, it uses entity actions to
communicate to itself on the client side to show a UI alert informing
the user.
Erno was wondering if simply sending the old kept value back from server
would work ok to enforce same state on the client. This might be even
quite ok in the UI .. if you try to edit a field in EC editor that you
are not allowed to, it would always reset back to the server value after
you edit.
Plan is to only have these hooks enabled on the server, which is
authorative -- we thought that typically client is not supposed to
reject data from the server. Erno was wondering if that'd be useful
sometimes, and it's trivial to enable/disable in the code (it's the same
syncmanager anyway, that just checks for client/server mode if the
behaviour is to differ). But I think we can first go with the server
only idea, easy to enable if someone really needs on the client, but
perhaps better first without as it can be just confusing.
These signals fire for individual changes as they come -- there is no
support for transactions that you could reject as a whole. We figured
that when someone needs such larger batches of changes, can implement
those as an entity action (a remote function call).
> ~Toni
same.
Toni Alatalo
> signals now -- I'll start implementing when get the chance, perhaps a
> first step on coming Monday .. then is a bit unclear with the holidays
> etc. This is the plan anyhow:
Got the first step indeed mostly done on Monday, and completed it now.
Decided to start with this overall all reaching signal:
> We were also considering a simplification, so e.g. a simple permission
> check to disable all editing doesn't need connecting to many signals ..
> this would suffice to prevent any remote changes to the scene on server:
> - AboutToModifyEntity
> * emitted for Create/RemoveComponent and Create/Modify/RemoveAttribute
Am now emitting that also for Create/Remove entity, so that one signal
works for preventing any remote editing of a scene. The entity parameter
is null for the CreateEntity message.
Tested that it works with this Javascript thing,
https://github.com/realXtend/naali/blob/tundra/bin/jsmodules/apitest/permissioncheck.js
(by doing ./server --run jsmodules/apitest/permissioncheck.js)
This actually suffices for many traditional, as in pre-made, apps -- for
example the Chesapeake bay LVM app, the reference / default avatar app
etc. don't modify attributes etc. on the client side but just send
actions and the server runs the logic.
So you can just copy that js file to the jsmodules/startup/ directory on
your server, and should be good to go to host a public server without
the worry that anyone can login with a normal client and use the
scenestruct gui to delete the whole scene etc.
The logic is easy to combine with some sort of authentication, so that
e.g. only clients that give a certain password at login can edit. Except
that I forgot to add the UserConnection ref to the signal, will add that
next :p
The fine grained signals for individual attribute changes etc. are, I
figure, needed for apps where e.g. some custom UI allows users to modify
the URLs of some webviews, but nothing else. I'll implement those at
some point.
Current implementation leaves the unauthorized client in a non-synced
state, for example if it deletes an entity, it gets to delete it for
itself, even though the server then rejects that change so it doesn't
happen for anyone else. Same for rejected attribute changes -- they
happen in the client that makes them, but nowhere else. Erno's idea of
just sending the old state back to the client might work ok to help with
this, and I've been thinking that scripts in apps can do custom UI
notifications etc. if want to give more info of when that happens (e.g.
if in TOY someone can only edit objects that has rights to etc).
Current code doesn't have extra checks to fire these signals on server
only, but those are easy add if really needed (is how we designed it).
Seems a bit unnecessary as it's easy to just enable the logic on server
only, but perhaps good to add still so that someone doesn't run these in
client accidentally?
~Toni
> -Server::UserAboutToConnect (already implemented, works for auth)
> -SyncManager::
> - AboutToCreateEntity(UserConnection *source, MsgCreateEntity &entity)
> - AboutToRemoveEntity(UserConnection *source, MsgRemoveEntity &entity)
> - AboutToCreateComponent(UserConnection *source, Entity *target, comp)
> * the list of components from net msg split to individual calls
> - AboutToRemoveComponent(UserConnection *source, Entity *target, comp)
>
> - AboutToModifyAttribute(UserConnection *source, IAttribute
> *targetWithOldValue, QVariant newValue)
>
> * For DynamicComponent:
> - AboutToCreateAttribute(UserConnection *source, IComponent *target)
> - AboutToRemoveAttribute(UserConnection *source, IComponent *target)
>
> And for Entity-Actions: