bzt wrote: ↑Thu Aug 26, 2021 14:57
You're still missing the point, neither of these will solve the issue that multiple mods might implement the same node. This would add huge bloat to every schem without any real benefit.
I understand that this does not solve the problem of multiple mods registering nodes with the same name, but at least I can know which mods are used by schematics. It's no benefit from the creator's perspective, but from the user's perspective... eg, I can not even use your example schematics for using minetest-game.
Yes, this way can only be regarded as a temporary and simple solution: you don't need to list the use of mods in an additional documentation, just download schematics and use it.
And the author just upload the schematics file to forum, no additional explanation is required at all, the forum can directly read the file and display the relevant information.
bzt wrote: ↑Thu Aug 26, 2021 14:57
No, it is not. I haven't seen any IRL blueprints that would explain the material. For example a blueprint for a house just refers to concrete, but it never contains a detailed description of how to create concrete or what the actual chemical composition of the concrete is.
If we want to build the
metaverse("internet") of the game world, then such a blueprint is indispensable. I hope that in this way, schematic creators can focus on design and creation instead of focusing on different games.
Without such detailed description how to create object via schematics across games/applications?
bzt wrote: ↑Thu Aug 26, 2021 14:57
snowyu wrote: ↑Wed Aug 25, 2021 07:43
And this makes it easier to share schematics in different game worlds.
Absolutely not. How would you manage the event handlers of the nodes? There's a good reason why a mod registers the nodes, because that same mod must also implement the event handlers for the node. Even if you store the entire mod with all the Lua code in the schem, that's just waste of storage space and wouldn't provide shareability (a schem with an MTG mod in it wouldn't load into an MCL world because that mod isn't compatible with the MCL game).
Yes, the only thing schematics can do at most is the view, and interaction is not possible, at least for now.
If you want to achieve interaction, I think it is more appropriate to upgrade to the 3D Component standard, similar to Web Component. There is no such standard currently.
The only simple "interaction" is through the properties of matter:
Only when the blueprint has the attributes representing the nodes, the application can determine whether the building can be blown away by the wind or burned in the environment where it is placed.
Of course, these are unnecessary if they are in the same game world.
bzt wrote: ↑Thu Aug 26, 2021 14:57
If you want to move schems between different worlds, use a tool like MTSEdit or Sokomine's
Handle Schematics to replace the technical names and you're good to go.
This is a terrible experience. I have to waste more time on this. Originally, I didn't have much free time.
I am not a 3D designer or game creator. I just wanna use MT to teach my kid(cognition of architecture,gravity, acceleration, etc.). Placing some buildings in the game world is a minimum. So I have to search for real simple schematics and find this discussion.
The
roblox has done a little simplification and integration work to brag about the "metaverse", in fact, it is still very early too. I believe metaverse is not a commercial company can be made out.
bzt wrote: ↑Thu Aug 26, 2021 14:57
If you could, then I would just use that instead of having hard time figuring out the minimal changes required for MTS. By the way, it is ready, well-documented, well-tested, integrated into multiple FOSS projects, which is a lot more than your (as of now) fictional format. That's why I've recommended it. If you want to add such support into the MT engine, use an existing, known-to-work library, don't try to reinvent the wheel.
It's good as a low-level schematics library. It's better if can support the sem-version info in M3D format. And a little questions:
- Could the skeleton specify the range(limits) of motion angles?
- Could reference another schematics file as component?
- how to specify the rigid body, fluid or soft body as component?
bzt wrote: ↑Thu Aug 26, 2021 14:57
As I've noted before, IRL blueprints does not store ingredients, texture etc. information either, just a reference to the material to be used. Same with MTS, therefore MTS is a blueprint.
I do not know what's the IRL blueprint. I just know the architectural blueprint. I found that what we discussed may not be on the same channel.
My care is the schematics standard how to be used in any 3d game application. How can it be simpler and make it easier to use for those who are not very proficient in 3d(include me). At least It could be extened in the future.
Code: Select all
| Offset | Length | Description |
|--------:|-------:|------------------------------------------|
| 0 | 4 | magic "MTSM" |
| 4 | 2 | file format version, 5 |
| 6 | 2 | size X |
| 8 | 2 | size Y |
| 10 | 2 | size Z |
| 12 | 2 | ground Y |
| 14 | 4 | The addtional info length |
| 18 | x | The addtional info can extened for future |
The addinal info:
Code: Select all
| 0 | 2 | The Major Versoin number |
| 2 | 2 | The Minor Versoin number |
| 4 | 2 | The Patch Versoin number |
| 8 | ? | The author (pascal-str) |
| x | ? | The license (pascal-str) |
| x| 2| The count of mods(Temporary solution) |
| x| ?| The first mod name (pascal-str) |
| x | 2 | The Major Versoin number of the first mod |
| x | 2 | The Minor Versoin number of the first mod |
| x | 2 | The Patch Versoin number of the first mod |
...
pascal-str: the first byte is the string length.
The optional node descriptor(instead of mods, but need engine do more):
* id:node id
* name: the general name, eg, copper, iron, tin ...
* characteristics: optional
* color
*
refractive index
*
extinction coefficient
* luminous(light) intensity
* texture
* density
* liquefaction temperature(melting point)
* vaporization temperature(becoming gas)
*
electrical conductivity
* ...