thanks
Ergebnis 61 bis 80 von 121
-
- Registriert seit
- Feb 2011
- Beiträge
- 4
-
- Registriert seit
- Aug 2009
- Ort
- NRW
- Beiträge
- 81
Is it working correctly now?
Geändert von Galrath434 (10.07.2011 um 11:51 Uhr)
-
- Registriert seit
- Feb 2011
- Beiträge
- 4
yes, i opened this file does not
-
- Registriert seit
- Aug 2008
- Beiträge
- 174
I tried to modify some .tple files but much to my disappointment found out that those modifications have zero effect on the entities already present in the game world (i.e. inside .lrent files). So the changes need to be done in the .lrent files. I wonder if .lrent file format description is available anywhere? If not, Galrath434, maybe you can provide some useful info on that format? Thanks in advance.
-
- Registriert seit
- Aug 2009
- Ort
- NRW
- Beiträge
- 81
Yes you are correct when assuming that changes have to be made in the lrent files. This is because I don't do anything with the .tple files.
Well, the lrent structure is not that easy to explain and I actually have got all my info from Nico. If you really would like to know I could probably tell what you want to know. Another option would be for you to tell me what you would like to do so I can integrate such functionality in the Lrent Viewer. This would have the additional benefit of everbody beeing able to use this new feature.
-
For information about the .lrent format use this tool by NicoDE.
But as you're familiar with the SDK I'd recommend you to try out eCTemplateEntity::PatchInstances.
If that works and you want to save the affected .lrent files, you can use the Script_Mod_Extensions module (have a look at the .txt file before using the .dll). The command you need is "World Save", but it does not work with packed .lrent files, so unpack all of them and delete or rename projects.pak.
-
- Registriert seit
- Aug 2008
- Beiträge
- 174
If you find it hard to explain the format maybe you can upload lrent viewer source code or its part where the structures are defined and .lrent file is loaded?
Meanwhile, I was able to successfully change some values by hex-editing .lrent file. Unfortunately, I also need to add or delete some properties (such as remove item from NPC inventory or add new item to an array, for example, add item of type "QuickUse_Player_MeleeWeapon" to Interaction array for forged swords) and that would require knowing full file format (to shift data and update all offsets properly).
Atm I understand the part of .lrent file that is described here genomfle.txt. Also, I understand a bit of what goes between file header and 0xDEADBEEF signature. In particular there are records like this: tag (index to string table), type (index to string table), magic value (0x1E00), size, value. But what goes after the file header and before first such record for example? Also how do you find a start of the data for particular entity in the .lrent file?
-
- Registriert seit
- Aug 2009
- Ort
- NRW
- Beiträge
- 81
Send me your Mail address per private message and I will send you the source code, though be warned it is C#.
Editing inventories is easy, load a lrent containing NPC's, select one, open View/Character Form. Then you will be able to add/remove items from the inventory.
-
As I said, use risenvim and all your questions concerning the .lrent format will be answered.
-
- Registriert seit
- Aug 2008
- Beiträge
- 174
Is there something similar for .tple format?
Saving .lrents as done in Script_Mod_Extensions has the following side effect: it works only while the game has been started and is running, i.e. NPCs are busy with their routines, etc. As a result saving .lrent produces different file all the time as NPC positions and probably some other data slightly change all the time as the game is running.
I tryed to do the following without starting new game/loading savegame:
Code:gCWorld* pWorld = dynamic_cast<gCWorld*>(gCWorld::CreateObject()); pWorld->Load(bCString("E:\\Games\\Risen\\data\\common\\projects\\World\\World.wrl"))) gCSector* pSector = pWorld->GetSector("Harbour_Town_NPC_01"); pSector->Save();
Some suggestions for Lrent Viewer improvement:
1. Ability to group or filter entities in the "EditScene" window by .lrent file they belong to.
2. Ability to see GUID of the entity in the properties panel.
3. Fix bug: "EditScene" window can be increased in size but not reduced.
4. Ability to toggle what .lrents are drawn when multiple .lrents are open.
5. Ability to close all opened .lrents.
6. Sort entities by name in the "EditScene" window.
7. Esc key should not close the program!
Also would be nice to have latest version of Lrent Viewer available for download on the first page of this topic.Geändert von PowerGamer (31.07.2011 um 16:05 Uhr) Grund: Added suggestions for Lrent Viewer improvement
-
No. But I guess the .tple format is not too different from an entitiy's (within a .lrent file).You could minimize this effect by executing "timescale 0" (in fact it is still >0) while the loading screen is active and pausing the game as soon as it starts. This might be achieved by overwriting the OnGameStart script so it calls World::Pause and then starts the original (overwritten) script.
Maybe it's already sufficient to change the player's start coordinates (should be in _Intern.lrent) so there's no NPC in range.I don't know any way yet to get all the stuff loaded without starting a new game.
And I thought gCSector::Save was only for saving the .sec file...
-
- Registriert seit
- Aug 2008
- Beiträge
- 174
Overriding OnGameStart() with world.Pause() code have not helped to produce byte identical .lrents when saving them with the "World SaveSector" command. I was saving Harbour_Town_Dyn.lrent which contains entities far away from the starting position of the player and theoretically should not contain any entity that change its properties during the game course, yet still the created file was different from the original .lrent file.
I never claimed otherwise.
-
Galrath434 reported a similar problem today (property sets that "shrink" upon getting loaded by the engine).
I'm going to look for workarounds.I just didn't see what the purpose (in saving sectors) would be if it was not to save all the related .lrent files.
-
- Registriert seit
- May 2005
- Beiträge
- 1.238
-
- Registriert seit
- Aug 2008
- Beiträge
- 174
With regard to producing byte-identical data files. I experimented with manipulating .tple files using SDK. Here are results:
1. I was albe to read and save .tple file without starting new game/loading savegame.
2. Reading and saving Sergio.tple produced byte-identical file.
3. Reading and saving It_1H_Club.tple produced a file with several different bytes. Upon investigation in hex editor I found out that different bytes belong to 4 bytes _vftable pointer of bCFloatColor class that along with its 3 useful data members also saves its _vftable pointer (for performance reasons it seems). Naturally when these bytes are read back by bCFloatColor class they are overwritten with real value of _vftable pointer (I checked that code in SharedBase.dll). In other words this difference is absolutely safe to ignore.
4. Saving and writing It_2H_Steel_Sharp.tple produced a file different by size and content. New file was bigger because it had 2 new int values added: VelocityLeft and VelocityRight of class eCStrip_PS. Upon removing from the file added data belonging to these values (by manually hex-editing) new .tple file became the same size as original with only a few different bytes. I managed to find the meaning of each byte that were different. In particular several bytes where different for the same reason as in p3. The rest of the bytes belonged to offset of DEADBEEF text string section of the file and several "size" and "count" fields that took into account added values of VelocityLeft and VelocityRight of class eCStrip_PS.
5. Upon a simple search among some .tple files it appears that some of them already contain VelocityLeft and VelocityRight values, while others do not. That may mean that some .tple files where created with older version of game code (when eCStrip_PS class did not have VelocityLeft and VelocityRight members). So the presence or absence of these values is properly handled by the game and is a normal situation.
6. I was able to modify gold value of an item programmaticaly (using SDK functions) and successfully saved modified template (which was byte-identical to original except above differences that are normal and new gold value of course).
Conclusions:
1. Loading-saving .tple files using SDK may produce non-byte identical files but differences are OK and to be trusted. Obviously doing the same with .lrent files may not produce byte-identical results for the same reasons.
2. It still would be nice to find a way to load and modify .lrent files without starting new game/loading savegame (because of what we discussed earlier).
3. It seems already possible to edit .tple files in a best possible way - using game engine through SDK.
-
- Registriert seit
- Aug 2009
- Ort
- NRW
- Beiträge
- 81
Respect for the great work you are doing!
After reading your description of what you have achieved I have one question : Would it be possible for me to use the SDK to create an "easy to use .tple editor"(to integrate into the Viewer)?
In other words is it possible to create a custom application totally indepentant from risen.exe. Which only uses the SDK to do the work. Because this would be neccessary for integrating it in the Viewer.
If it is possible could you maybe give me some help how I should proceed? What classes are needed to load a .tple file and modyify it?
I have nearly no excperience with the sdk so any help would be appreciated.
P.S. If it is easier for you to do, your source code would suffice too I guess.
-
Thanks for the clarification!
I have to admit I never had a deeper look at .tple files so far.
@PowerGamer
Thank you for sharing the results of your tests. I agree. But here, the workaround (shifting start point; overriding OnGameStart) may work, if indeed getting byte-identical files isn't possible anyway.
Btw.: Did you try using eCTemplateEntity::PatchInstances and did it work for you?
(I didn't test it yet so I'm curious)
-
This is an Engine bug. Read my notes about random bytes in the shader materials.
ps: sorry for being absent/silent during the last months - I just returned from paternity leave and at the moment it’s crunch/release time at work.
-
- Registriert seit
- Aug 2008
- Beiträge
- 174
For now when modifying .tple I created console command (not a standalone app that uses game engine) and modified only one simple value of template (gold cost of the item).
I think it is a bit early to speak about creating .tple editor because:
1. AFAIK no one (except I think NicoDE, maybe he will share his research on this matter with us?) tryed to create a standalone app that uses SDK.
2. A lot of classes (mostly property sets related) are still to be recreated and added to the SDK to allow for any meaningful manipulation with the content of .tple files.
BTW, Galrath434, you may want to add another definition to Lrent Viewer - a value of type bCFloatColor is stored in the Risen data files as follows: 4 unused bytes, 4 bytes float red, 4 bytes float green, 4 bytes float blue.
Also I wonder if Lrent Viewer with ability to delete NPC inventory items will be made available soon?
Nope I didn't use PatchInstances. Some changes I wanted to make were easier to make by manually hex-editing .lrent file (only single byte was needed to be modified). The changes to NPC inventory are not related to .tple (since inventory is only stored in .lrents). And I think the changes to interactions (currently working on that) need to be done only in .tple (not .lrent). So I do not need PatchInstances atm.
I wouldn't call that a bug, it seems to be intentional feature (of dubious nature due to relience on implementation-specific language mechanics) to improve performance (see my explanation here).
-
Just as a side note: I’m still working on the task to get rid of the Risen.exe, but it will take time (the full list of dependencies is huge, and I have to decided what to skip to get it done in a reasonable time frame).
Baltram has r/w access to the SDK. This month I will take the time to merge his branch into the trunk (after some small code style/spacing modifications). I’m still open to requests for new user branches