First, install PyBluez (0.9 or later) and OpenOBEX (1.3 or later) Make sure you have installed the python development package for your distro (e.g. Python-dev on ubuntu) or else you will get compile errors. $ obexftp -b MACaddress-g filename Note: Ensure that the file you are retrieving is in the device's exchange folder. If the file is in a subfolder of the exchange folder then provide the correct path in the command.
Ciao a tutti. Ieri sono entrate stabili nel portage tree le bluez-utils-3.36.
Ho fatto l'aggiornamento e revdep-rebuild segnalava di dover ricompilare i seguenti pacchetti:
Code: |
app-pda/libsyncml:0 dev-libs/openobex:0 net-wireless/gnome-bluetooth:0 app-pda/multisync:0 net-wireless/libbtctl:0 |
Code: |
.. checking for bluetooth/bluetooth.h.. yes checking for hci_open_dev in -lbluetooth.. yes checking for sdp_connect in -lsdp.. no checking for correct SDP lib version.. checking for OBEX_Init in -lopenobex.. yes checking for working openobex.. configure: error: You must have openobex 0.9.8 or openobex >= 1.0.0 installed. !!! Please attach the following file when seeking support: !!! /var/tmp/portage/app-pda/multisync-0.83_pre20050414-r4/work/multisync/plugins/irmc_sync/config.log * * ERROR: app-pda/multisync-0.83_pre20050414-r4 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 4194: Called run_compile * environment, line 3728: Called econf * ebuild.sh, line 543: Called die * The specific snippet of code: * die 'econf failed' * The die message: * econf failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/app-pda/multisync-0.83_pre20050414-r4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-pda/multisync-0.83_pre20050414-r4/temp/environment'. * >>> Failed to emerge app-pda/multisync-0.83_pre20050414-r4, Log file: |
Questa anomalia è segnalata come bug qui, ma ancora non ha soluzione.
Ora, siccome il mio mouse bluetooth non va più da quando ho fatto questo aggiornamento, qualcuno ha idea di un workaround per risolvere il problema?
Grazie in anticipo.
_________________
A cow enters a supermarket, does an handstand and dies.(Public toilet graffito)
Last edited by canduc17 on Thu Mar 05, 2009 8:02 am; edited 1 time in total
Roadmap for the Future
This is Michelle's roadmap to future versions of openBVE, subject to change. Retrieved from the old OpenBVE site.
_________________________________________________________________________________________________
Goals
The following summarizes the main goals:
Managed add-ons
The majority of routes and trains have to be downloaded and installed by users in potentially obscure ways that are all but easy and intuitive. With managed add-ons, an official add-on directory was added which the game can directly query to show what is available to download. Add-ons can then be downloaded and installed automatically with the mere click of a button. When newer versions of add-ons are available, they can be updated easily as well.
Was introduced in 1.3.2.
More sophisticated renderer
At the moment, the renderer is heavily tied to the concept of 'track positions' which is inherited from the CSV/RW route formats. This means that the renderer decides which objects to render at any given time based on what track position the camera is currently located at. As long as openBVE simulates a single rail, this is an acceptable concept, although it means that the camera cannot freely roam the world - it can only be moved relative to the rail. For an interconnected network of rails, this concept does not work at all, and so a new renderer will be designed that manages objects by placing them on a 2D grid. It can then decide which objects to renderer by examining which gide node the camera is currently in, and which other grid nodes are visible from that location.
Additionally, the current renderer uses mostly immediate mode rendering, which means that every object that is to be renderered is sent to the graphics card every single frame. This is very slow and limits the number of objects and the complexity of objects that route developers can utilize. The new renderer will store objects on the graphics card so that less transfer between main memory and the card will be necessary, greatly speeding up the rendering process.
Planned for the 1.5/1.6 series.
Changes to track representation
At the moment, openBVE only simulates a single rail on which trains can drive on. Everything else is purely decorative. This is going to change so that an interconnected network of rails is simulated. The primary goal is to allow opposing traffic, for players to choose trains services that operate in either direction within the same route, and to develop routes that can be driven forth and back continuously (single rail or double rail with switches). The CSV/RW formats will allow some of these features, while others might only be available via new formats or editors.
Planned for the 1.7/1.8 series.
Cars and consists
The the moment, trains are inseparable units, mainly because the existing train formats do not work on individual cars, but on the train as a whole. This is going to change. All future train formats will be based on individual cars so that they can be freely combined into consists. This also opens up the possibility of coupling, decoupling and associated shunting operations during the game.
Planned for the 1.9/1.10 series.
In-game menu system
At the moment, openBVE uses a main menu based on Windows Forms that precedes the actual execution of the game. As such, a number of things cannot be done, for example easily configuring keyboard controls, accessing the menu from within the running game, loading a new route from within the game, and so on. Eventually, a new menu system will be developed that is entirely in-game without depending on Windows Forms.
Planned for the 1.11/1.12 series.
Modularization and plugins
At the moment, loading textures, sounds, objects, routes and trains, as well as simulating engines and brakes is achieved through functions built into openBVE. This is going to change so that external plugins perform these functions. The safety system plugins have demonstrated well that this degree of extensibility and flexibility is indispensable. The modularization of the source code also means that the individual components will be less interwoven than they are now, leading to smaller, cleaner and easier-to-maintain code in each component. This modularization is an ongoing process that will not be complete until very late in the 1.x series.
Openobex 1.3 For Mac Keyboard
_________________________________________
Milestones
The following is an overview of important milestones which were already released, which are currently in development and which planned for future releases.
1.2 (stable)
1.2.10
Runtime train plugins based on .NET can be used on all platforms. They supersede the older Windows-only plugins.
1.2.12
The default safety systems ATS and ATC were outsourced into a plugin in order to streamline the source code.
1.3 (development) and 1.4 (stable)
This series focuses on two major improvements. The first is occurring behind the scenes and advanced the modularization, namely support for textures and sounds via a clean plugin architecture. The existing BMP/GIF/JPG/PNG/TIF loader and the WAV loader have already been made plugins, and support for ACE textures and FLAC sounds was introduced. The second and more obvious feature is the addition of managed add-ons.
1.3.0
The API for textures was implemented. The existing BMP/GIF/JPG/PNG/TIF loaders were made external plugins. The ACE texture format is now supported.
1.3.1
The API for sounds was implemented. The existing WAV loader was made an external plugin. The FLAC sound format is now supported.
1.3.2
![Openobex 1.3 for mac Openobex 1.3 for mac](https://setatakahashi.files.wordpress.com/2014/10/synocommunity_03.png)
Support for managed add-ons was added, allowing users to browse and install add-ons directly from within the game.
1.5 (development) and 1.6 (stable)
A new renderer based on a two-dimensional quadtree will be implemented which will allow to roam the world freely. This is a prerequisite for more than one functional rail which will follow in later versions. Performance will also be greatly increased. The CSV/B3D, X and ANIMATED object formats will be made external plugins. The renderer may too so that it could be reused directly in other applications, such as the various viewers or potential editors.
1.5.0
This will be the first release in the 1.5 series. No details are available yet.
1.7 (development) and 1.8 (stable)
Allow for routes to be loaded via external plugins. The internal track geometry will be completely redesigned in order to allow networked tracks. At the end of this development cycle, routes can be built on which train services can run in any direction, including AI-controlled opposing traffic, an express train passing a local train, and the like. The CSV/RW formats will be expanded so that some of these features can be implemented in existing routes. A route editor is also being considered.
1.9 (development) and 2.0 (stable)
Rewrite all simulation-related components such as engines and brakes, implement new types of engines and brakes, and likely allow parts of these things to be externalized via plugins. All simulation-related components will work on individual cars, which will allow to freely combine individual cars into consists, likely also via the GUI once this has been rewritten. Coupling and decoupling of cars during the game will be possible to allow for shunting operations. Train loaders will be made available as external plugins as well.
2.11 (development) and 2.12 (stable) Picopix viewer for mac.
Openobex 1.3 For Mac Catalina
Implement a fully OpenGL-based menu system and abandon Windows Forms.
Running the site isn't free. Please help us by donating.
Openobex 1.3 For Mac Operating System
© Copyright 2012 openBVE Connection