Pink Petal Games
Feedback => New Features => Topic started by: betatester on January 30, 2010, 06:00:43 AM
-
Some things aren't saved but should be
- the slave market
- the shop inventory
With the God of Reload you can buy what you want, save the game, pray the god of reload and buy new things again... ad nauseum or until you've got what you want.
-
Technically, you are correct, that stuff isn't saved and probably should be, but fixing it is going to be back-burnered. It will probably get fixed along with other saving issues (like the job state for girls taken off duty by the matron) when the save files are converted over to XML format.
-
It has to be but on the back burner for now, I will need to fiugre out how to track items without using thier names first though.
-
It has to be but on the back burner for now, I will need to fiugre out how to track items without using thier names first though.
Time to assign everything an ID number! :D
Oh and of course, randomly generator ID numbers for all the expansion girls and items! ::)
-
I have three methods to solve the problem:
1) Use item codes. Create a format something like: [item type]_[creator]_[id]
so if I created a series of healing potions, the codes would look something like:
Consumable_Zodiac44_Healing1
Consumable_Zodiac44_Healing2
Consumable_Zodiac44_Healing3
Item type should be assigned by the editor, the creator's name and item ID should be entries in the form. The editor could check the item code against other items in the same file for duplicates, and require the ID to be changed if it matches an existing entry. This doesn't prevent collision from other item files, so you would still need collision detection and resolution in the code, but it helps a bit.
2) Change the manner in which items are collated. Each item gets its own file and they are referenced in game by file name. In this system, the game doesn't need collision detection and resolution, as it is all handled at the time of item creation. Players could overwrite an item's file, which would change the item in game, but there wouldn't be any collision in game. As I think about it some more, this system would need a file naming convention similar to the one posed above, to prevent overwriting an item with an incompatible item (ex: overwriting an armor with a necklace) which could present problems in game.
3) Save all items in the save file the same way girls are handled. Assign a random ID number to each item (or use the system above) to differentiate between items (and girls?) of the same name.
Personally, I favor the second option, implementing a similar scheme with girls to prevent accidental duplication in game. Break the composite .girlsx files into the individual girls and place each girl's file in her image folder. This would simplify a number of creation and editing tasks for items and girls, as well as making distribution and pruning somewhat easier.
-
If you're going to do item IDs I would favor the system Bethesda used for Oblivion and Fallout 3.
When the item/girl is created in the editor is is given one unique ID, that does not change unless the item is deleted, based on on the Computer and Time of creation. Then whenever the game loads, it finds all the items and girls and references those IDs. This way the item can stay in the game even if it is modified, and than later reloaded. If however the item/girl is deleted and then recreated, it will have been given a new ID.
Any item/girl in the save file whose ID can not be found, when the game is loaded, are simply ignored, and their state changed to something that won't cause a conflict should they be reloaded later on after a save. (Missing girls are flagged as in the Dungeon, Items are set to the player's inventory.)
This still allows for large girl and item indexes to be created in the editor. However, it would require more programing on the editor side.
-
That would solve a lot of issues if we gave each girl and item a unique id code and would cut down on the save file size.
-
I was thinking along the lines of the Neverwinter Nights system, but Oblivion/Fallout works as well. The catch is to determine a method to generate the ID that is unlikely to produce duplicates. The scheme I proposed puts the onus on the creator, but also makes it unlikely that any duplicates will arise.
I'm not sure how much save space you could cut down, as you will still need to track changes to girls in the file. I suppose you wouldn't need to track as-yet-unobtained girls in the file, though.
-
A simple 4-byte Hexadecimal code (00000000 - FFFFFFFF) based on the the machine and time of creation should prevent any conflicting items/girls.
The less the user has to do, to make sure his work is compatible and conflict free with the game, the better.
-
The majority of the save when you start a new game is what unique girls and thier stats were available when the game starts.
-
Yeah, you'd save a huge amount of space in the early game, I was thinking more along the lines of average case for mid- to end-game saves.
-
Or maybe save the item table, and then use offsets into the table as IDs. We could (and probably should) let modders create a namespace so they can create named things that won't conflict with standard things of the same name, or similarly named things from other modders.
-
If the item has a unique ID it shouldn't matter what you name it.
-
Yeah. But who allocates the IDs? And when? And if allocated at game start, how do we tell if an item added in between saves is the original, or a new one from an expansion? And if a new one, how do we know if it's intended as a replacement for the existing item, or a new item that just happens to clash.
I don't particularly want to maintain a central registry of IDs, and I don't really want to force players to start a new game for each girl or item pack they add. Namespaces seem like the simplest solution
-
you can also save all the items data and then it doesn't matter where it comes from.
If you want an unique ID make an MD5 transformation with a string with the item xml description...
-
Saving the item data or generating ID's automatically (in the MD5 example you gave) would require the player to start a new game in order to use items that he changes properly. Having a user-generated ID's based on a well-defined namespace is simple and effective. It is, in fact, the preferred method employed by game developers who intend to have user-created content in their games (see NWN, Oblivion, Fallout, etc).
-
Hmmm, this wouldn't be very difficult to implement. The suggestions here for methods of generating IDs are useful. There will always be a chance of conflicts but using a combination of time stamps and computer specs would reduce this to effectively nothing. As mentioned though it will have to be on the back burner for a while.
-
my md5 method works well if you save all the owned and present in shop item data in the saved game.
You use the .itemx files only for generating new items.
if you modify an object in the .itemx file => new ID the old and new version exists but are not equal and don't stack anymore
Since you keep all the owned and buyable item data in the samed game if you delete an item in the .itemx file you don't have any problem since the item still exist in the saved game as long as someone owns at least one. The deleted item is not generated anymore since you use the .itemx
The md5 system is independant of computer so you can exchange saved games (usefull for debug)
it can be used for an Equipment.equals(Equipment) method.
-
Here's where the MD5 system fails:
Create and item (say, "Potion of Healing" that gives +10 health).
In game, buy a Potion of Healing, save game, exit.
Edit item in editor (say, change potion to +20 health), save.
Load saved game. Now, if the game saves the items' effects, you have two Potions of Healing in the game. One gives +10 health, the other gives +20 health. Apparently, you don't see a problem with this. In every other game I've played that allows users to modify items, the changes apply to all copies of an edited item in the game. They do not generate a new item that is wholly separate and distinct from the original. The system you proposed breaks players reasonable expectations.
I could see using an MD5 method to generate a unique ID the first time an item is created in the editor. Subsequent changes to the item should not generate a new ID, unless the item is specifically saved as a new item.
I vastly prefer user generated ID's in a well defined name space, though.
-
For an id system I am thinking about using the file name and the item name. That should be unique enough for our purposes and will allow for some basic checking in case the user removes the items file. This also has the bonus of not needing to change the item file.
-
I think that a define namespace Misc-LSpack-Abortion2 is a better system than the MD5 because you can edit files with only a text editor
just be careful with modify, delete, creation of items with the same name but with different effects (see philter of abortion in LSItem pack) and stacking.
This topic is not about a system but about the necessity to save in the savefile the item description of all item owned by master or girls and shops. If an Item file is deleted it still works and you can't reload to respawn the shops.
On the other side the new possible item stack is loaded each time you load a game, it's dynamic and any modification is used asap (there you can, if you want, checked it the owned items if you have to modify the item array based on unique ID).
-
For an id system I am thinking about using the file name and the item name. That should be unique enough for our purposes and will allow for some basic checking in case the user removes the items file. This also has the bonus of not needing to change the item file.
Right off the bat, this conflicts with LS's items pack, which has several items with the same name but different effects (the abortion potions come to mind). I don't know if the game handles them correctly as is, but they would definitely cause collision with a <file name><item name> ID.
-
*cough*[00000000] - [FFFFFFFF]*cough*
That's 16^8 combinations... or 4,294,967,296. ::)
-
So?
-
Fine add the number of what item it is in the pack at the end of what I suggested and that issue is fixed, and I don't think the game tracks it correctly anyway.
-
Well, my solution of using several items with the same name but different effects is just a basic kludge. If a legitimate way to get some random item effects is ever implemented, this won't be a problem. :D
I don't think the game tracks it correctly anyway.
As far as I've tested, it works, but not exactly as you'd think. The store generates the separate items randomly, but if you have multiples that stack up in your inventory, they seem to merge and only have the stats of one of the items. Using the Test brothel, you get seven identical Philtres of Abortion at the beginning (all of them are the -2 Constitution version, presumably because it's the first one on the item file), but if you get rid of all of them, and then buy one from the store, the new one you get is randomized "correctly". I would guess this has to do with how items stack up in the player's inventory but remain separate entries in the shop inventory.
-
that's exactly the way I though it worked (see my example with disguised slave band in your pack topic)... it's buggy because items doesn't have unique ID.
your choice to make multiple item with the same name is the only way to have actually some kind of random effect...
But maybe we could make another topic for discussing unique ID
-
that's exactly the way I though it worked (see my example with disguised slave band in your pack topic)
Oh man, that's right, I had forgotten about that... Heheh, I should have remembered, it would have saved me a bit of testing.
That's why I'm so nervous about whether it's my fault or not when I find out something doesn't work right with my stuff: I worry that I'm just being absent-minded again and forgetting something important or obvious.