The Laboratory Robot

A complete transfer of two OpenCart websites from one account to another within the same hosting provider is required. The reason for the transfer: the current account does not allow payment for services in the necessary way, so the projects need to be moved to another account of the same hosting provider. After the work is completed, both websites must fully function on the new account without data loss, settings, or functionality.What needs to be done Transfer two OpenCart websites with all files and databases. Transfer all settings, templates, modules, and extensions. Correctly connect the databases. Connect both domain names to the new hosting account. Make all necessary DNS or internal hosting settings changes (if required). For one of the websites, purchase and activate a license, linking it to the new domain name (if license transfer or new activation is necessary). Set up SSL certificates for both websites. Check the functionality: homepage; categories; product cards; cart; checkout; administrative panel; all installed modules; SEO and URL rewriting; form submissions and other core functions. Check for PHP, MySQL, SSL errors, and redirects. Perform the transfer with minimal downtime.Requirements The hosting provider remains unchanged — only the account within the same hosting is changed. After the work is completed, both websites must fully operate on the new account. All products, categories, images, SEO settings, templates, modules, and data must be preserved. The contractor must independently perform all necessary technical settings for the correct operation of the websites and domains.Result Two OpenCart websites fully transferred to the new account. Both domain names correctly connected to the new account. SSL works without errors. The license for the necessary website is activated and correctly linked. Both websites are fully operational and ready for further use.

A patch is required for the graphics card driver that expands the capabilities of managing the graphics adapter by adding additional user settings. The patch must integrate into the existing driver architecture without disrupting its core functionality and ensure compatibility with supported versions of the operating system. The main goal is to provide more flexible access to parameters that are not available in the standard driver control panel, with the ability to modify them through a user interface or software API. The patch should provide a modular structure that allows for the addition of new parameters in the future without significant code redesign. It is necessary to ensure proper error handling, change logging, the ability to revert settings to default values, as well as maintain compatibility with future driver updates as much as possible. The solution should be accompanied by technical documentation describing the architecture, implemented capabilities, limitations, and testing recommendations.

We are a large logistics company with our own exports. We have a large fleet of vehicles and we constantly send our own vehicles for export to European countries.Description Website: https://echerha.gov.ua/ On this website, we place our vehicles in an electronic queue for crossing the state border. During registration, the following data must be entered: driver's first and last name; foreign passport number; email address; logistics phone number for notifications; type of vehicle (cargo); manufacturer's name of the vehicle; state registration number of the tractor; state registration number of the trailer; customs declaration number. A specific day and time for crossing the border is predetermined for each vehicle. For example, the vehicle must pass through the "Rava-Ruska" checkpoint on Monday at 10:00.Our Problem - The queue on the website https://echerha.gov.ua/ moves unpredictably. - For example, today is Friday, and the vehicle must cross the border on Monday at 10:00. - We do not know exactly when the queue will start moving. This can happen on Friday evening, at any time on Saturday or Sunday, early in the morning, during the day, or late at night. - When the queue starts moving, it is immediately visible on the website. Sometimes, within just a few minutes, it can move from Friday to Monday or even to Tuesday. - Because of this, logistics personnel are forced to constantly monitor the mobile application or website to not miss the moment when the queue reaches the required date and time. If this moment is missed, we physically cannot place the vehicle in the queue for the needed time slot.Task - After entering the vehicle data (for example, into a table or another interface, depending on the programmer's implementation), the system should automatically track the movement of the queue. - When the queue reaches the predetermined date and time, the system should automatically fill in the necessary data and place the vehicle in the queue without the involvement of the logistics personnel.

Looking for an experienced TrinityCore 3.3.5a developer who has a good understanding of the core architecture, Battleground system, C++, SQL, and the WoW 3.3.5 client. A custom Battleground “Slavery Valley” has already been integrated into the project, transferred from AzerothCore to TrinityCore. The main part of the work has already been completed, but it needs to be brought up to Blizzard's standards.What has been done TrinityCore 3.3.5a + Eluna. The server is fully configured. The Battleground is integrated into the core. Entry into the BG works. Client UI works (partially). Most SQL and DBC have been transferred. Builds without errors.What needs to be done Fix remaining Battleground bugs. Bring the mechanics up to the level of official Blizzard Battlegrounds. Fix the match start phase. Implement correct starting gates/fire walls. Fix point capture mechanics. Fix match completion. Check score allocation and WorldState functionality. Fix remaining C++ and SQL issues. Conduct a full gameplay test.Requirements Mandatory experience: TrinityCore 3.3.5a; C++; SQL (MariaDB/MySQL); DBC; MPQ; Visual Studio; CMake; Git. Would be a big plus: AzerothCore; Eluna; experience in Battleground development; understanding of the client side of WoW 3.3.5a.Work format Work is staged. Mandatory testing after each stage. Each stage is accepted only after in-game verification. Clear reports on changes are required.In the future This is a long-term project. After completing the Battleground, the following is planned: transfer of new Battlegrounds; transfer of new arenas; new races; new classes; new game systems; further development of a custom World of Warcraft 3.3.5a server. Looking for a developer who has already worked with TrinityCore and can not only write code but also bring the system to a fully operational state.no server from 0 as I want If you are looking for a developer not just for one Battleground, but for creating a server from scratch, then the announcement should look something like this.Project Title Development of a World of Warcraft 3.3.5a server from scratch (TrinityCore / C++ / SQL / Eluna)Project Description Looking for an experienced TrinityCore 3.3.5a developer for long-term collaboration. I need a person who can develop a fully ready World of Warcraft 3.3.5a game server from scratch based on TrinityCore with further project development. The project is large and is expected to take several months of development.Project Foundation TrinityCore 3.3.5a. Maximally stable and close to Blizzard base. Eluna Lua Engine. MariaDB. Visual Studio + CMake. Git.What is planned to be implemented Fully operational server 3.3.5a. Fixing core bugs. Development of new game systems. Integration of custom Battlegrounds. Integration of new arenas. Transfer of useful modules from AzerothCore to TrinityCore. Development of custom modules. New PvP and PvE systems. New game events. Class balancing. Additional progression systems. Improvement of server performance.In the future After completing the basic part, the following is planned: new races; new classes; new zones; new dungeons; new raids; new Battlegrounds; new professions; new game mechanics; integration of modern systems into the 3.3.5a client.Developer Requirements Mandatory: Excellent knowledge of TrinityCore 3.3.5a. Confident knowledge of C++. SQL (MariaDB/MySQL). Git. Visual Studio. CMake. Understanding of TrinityCore architecture. Experience with Battleground, PvP, and game mechanics. Would be a big plus: Experience with AzerothCore. Eluna Lua Engine. Working with DBC and MPQ. Experience in creating custom game systems.Work format Work is staged. Each task is documented as a separate technical assignment. Mandatory testing after each stage. Work is accepted only after verification directly in the game. A developer is needed who can bring functionality to a fully operational state, not just write code.