Yes, I expected levels to be set, but after several tests now, warp is fine, toobar and inventory is fine, credits are fine (made sure to change so i could verify it was updated), but level and UP is set to start
Here is another thing, that i think might be a bug. We are running RE and we did the 1.3 - 1.4 Main game update and kept playing with most things looking really fine. However after running the conversion for IDs, this is the differences in old and new items list, and have in mind we are working with a custom scenario. And scenario items was changed and this messed up ships and bases massively. Have a look at the pictures below of before and after. What is happening here? Is it conversion gone wild? Or is it RE that is the issue?
Hey, hm not sure. the EAH conversion has no effect on the game (only problem that could occur is that EAH flags someone as cheater if the item is not known). But I can't say much about the items. For that I would need to know what RE has set those items to in the config. As fas as I see these items are all blocks. but in 1.3 blocks were only allowed up to the ID of 2048. So this should not have worked at all before. But maybe I am seeing it wrong. Anyhow, this is not a EAH conversion but something changed in the RE config. EAH reads the items from the config. To double check, you can search for those (blocks or items) in the RE config and then check the ID compared to the EAH items. Blocks should have same id as in EAH, items should have +4096 compared to the item config.
I did, and the new injected items did not have an ID, and it was the Convert database that changed the values to the after values. So the IDs are from before and after using the convert database under features item IDs So right now I am at the stage where i am about to update one server to have people using CSW over, and i dont know if the IDs should be the one or the other
Actually to use vulcan turret as example as it is first on the list, it is 1766 in the itemsconfig and gets converted to both those values depending on before or after database convert on the features items menu and in blocksconfig it is unnumbered
You might have to compare the blocks order in which they appear in your tool and their order in the config file. If some block has been removed or added, it will shift the order of the other blocks and will surely render older savegame unusable. When they allowed us to make custom blocks in the 2048+ range, they told us not to use ID numbers anymore, and that IDs would be assigned dynamically at game start, so that's why numbers can differ from one version of the scenario to another, if blocks have been changed/ removed. I asked the question on the updates thread regarding changes in the configs, reordering of blocks and consequences on savegames when I read that, but only got a speculative answer from another player. @ravien_ff has written some warning notices in his BlocksConfig.ecf around line 31543. You may want to ask him if he changed anything in his config recently, to see if this could be the issue, or if it's the "dynamic ID attribution" function that operates differently from one start to another. I think some pointers from the developers on this could help everyone avoid problems.
well all i can say is holy ****, have seen BPs now made for RE appear with all kinds of stuff in the wrong places. Even a Laser Gun pointing to the roof where a warp drive should be
The old Ids 0 to 2047 are written on Id. So if you use Block Id 5 lets say its a WarpDrive. You build a BP with this WarpDrive and save it Then you change Block 5 to a FuelTank. Then in the BP it will simple be a Fuel Tank Ids > 2048 are mapped in a special way. They dont have an ID in the ConfigFile (the Id is automaticly added by the game). There written with just a Name We provided some mapping way that when you change there order in the ConfigFile you still get the correct block in the BP But this mapping only works for the New Blocks Id 2048 to 4096 What did Ravien do in the 1.4 Update. He changed all custom blocks to the new Ids. IF he removed the old ones from the ConfigFile. Then he broke all the Blueprints aswell
I just figured it out. ravien had in 1.4 added some non ID items using the dynamic ID system, and in 1.4.1 update he added a few more, but them in the middle of the old ones, so that changed the IDs of all dynamic block IDs. This is very dangerous, and modders should be warned to always APPEND new items to the END of the items list, so that the new items gets a new dynamic ID and not takes the place of another one.
It wont work like that. Id after 2048 are picked by the game. If you remove something and this Id Opens up the game will fill it up again Hence we always say DO NOT REMOVE ANYTHING. Since Removeing breaks things
Ok Just to make sure I understand : If I make items in the 2048+ range, for example items A, B, C, D. Example 1: I can place them A, B, C, D I can change their order later to D, B, A, C and the game will assing ID numbers, but will match the items by names so A = A and B = B despites now having a diffrent ID number given by the game? Example 2: I make items A, B, D Later I add an item C to the list, now I have A, B, C, D The game will replace ID number of D and give it to the new item C, give a new ID number to D, and items will still match D = D ? Example 3: I make items A, B, C, D Later I remove item C The game will simply assign old C ID number to D, and if the game was saved with item C the item will be replaced by D or will cause an error because the "real" item names don't match ?
Well non ID blocks doesnt have a range like that, and my observation was the non ID blocks And if you look at the screenshots i have posted above here, it is IDs in the middle of that range and it switched around. And in ships suddenly a antigen warp drive was a laser gun, and ships got corrupted when removing because in the design there was a 3x1x5 item, and the item removed from its place was 1x3 and left ghost blocks that we couldnt remove
They do. They have an Id 2048 to 4096. You just dont see it in the Config File. The Game automaticly asigns this number
Then is it possible it's the very first case Taelyn explained a few posts above : the "missing" item was originally in the numbered range (so modded item lower than 2048) and was moved to the 2048+ range, but the blueprints still refer to a < 2048 item number ?
If you look at my screenshots above it is 2134 and 2133, so both times above the 2048 range And with this change, BPs should for Gods sake not refer to IDs anymore, as that can be different. So with this change i expect BPs to start using named blocks for everything above 2048
Read my message, 2133 and 2134 are the old range There not converted There not part of the mapping So replacing those devices with another device will make the blueprint show the NEW device As you say what was a warpdrive is now a turret > Exaclty what i said. Old Device replaced with a turret in the config files So warp Drive is replaced with a Turret in the Blueprint So again. Not a bug. Intentional Behaviour
And i am wondering one thing, where does EAH get its IDs from now. Because in a default install RE and latest EAH, the items list do not match that of the configs or the in-game H menu. Try adding a Bastion shield to your inventory from EAH and you end up with a Hydroponics Pod
