| Author |
Message |
| Tow dragon |
Posted: 2013-06-13, 15:28 Post subject: |
|
| There are a few open-source OpenGL GUI libraries. This looks interesting too: http://librocket.com/wiki . |
|
 |
| Ivan |
Posted: 2013-06-13, 12:00 Post subject: |
|
Tow dragon, good points.
Not sure if Coherent UI can be used in open-source projects - GPL limits commercial usage quite a lot. Including Coherent source code into VCMI means that it should use license similar to GPL. So anyone can just take our version of Coherent instead of buying one.
Maybe something like this:
http://sourceforge.net/projects/gigi/
Used by freeorion. And at least from player point of view it looks quite good. |
|
 |
| krs |
Posted: 2013-06-13, 10:55 Post subject: |
|
| Quote: | | Contact us at sales_at_*****.com for additional pricing options, academic and student licenses, source code access, redistribution options, and studio-wide licensing. |
The 99$ is intended for companies making "some" money out of it. Most likely a non profit open source project will get a discount. |
|
 |
| Tow dragon |
Posted: 2013-06-13, 01:27 Post subject: |
|
@Ivan
Actually I thought about using Coherent UI *on top* of current UI, with possible gradual replacement. Making a home-made UI solution moddable will be a great pain. That solution is based on HTML 5 and (AFAIK) should be compatible with just-a-lot-of-images approach.
Current UI is more or less complete if you only compare it to OH3 (without WoG). It still lacks a lot of things modders could want, e.g. layouts, general drag and drop, proper window system, scriptable event handling and more GUI primitives to begin with. And it's being rewritten to OpenGL anyway.
There is actually no good way out of this situation: maintaining old solution will gradually add complexity (and complex bugs) to it or leave modders with unfulfilled wishes. Employing an existing GUI library is a lot of work with no visible outcome. Either way we lose. |
|
 |
| Ivan |
Posted: 2013-06-13, 00:01 Post subject: |
|
Tow dragon, not sure if replacing UI at this point is a good idea - current one is almost fully functional and I'm not sure if we can find something suitable for H3 UI ("everything is an image" is not a popular UI concept).
Interesting that all SDL-based games I know use custom UI instead of some library.
I think that the only "low level" change our UI needs is more generic event handling - currently only several classes like button have something like this.
Creating set of function pointers (aka Qt slots) in CIntObject should fix this and will remove need of custom classes just for different popup message. |
|
 |
| Macron1 |
Posted: 2013-06-12, 23:00 Post subject: |
|
I propose new battlefileds modding also.
There are a lot of good battlefields, that can be added to VCMI.
I think it should be like
{
"battleFields":
{
"battleField1":
{
"image":"../FIELD01.bmp",
"terrain":"snow"
}
}
So then they could be added indepedendly, or in some town mod as addition. And random generator will choose current field.
} |
|
 |
| Tow dragon |
Posted: 2013-06-12, 21:26 Post subject: |
|
| Something like Coherent UI ( http://coherent-labs.com/ ) for GUI modding would be perfect. $99 would be affordable but I cannot find if they allow open source titles. |
|
 |
| Ivan |
Posted: 2013-06-12, 16:34 Post subject: |
|
The problem with such approach is that it will create tons of glue code to connect interface configuration with UI - every string you introduce in json must be manually connected with appropriate UI element. See current implementation of main menu.
Point #1 should remove need for most of trivial code we have in GUI right now.
Another issue is part of UI which was written long time ago - here you proposition won't work anyway until point #3 is fixed. Example - map selection/load game set of dialogs.
If somebody (from VCMI team or not) will fix these issues UI modding will become a viable option but until then - it's better leave everything as it. |
|
 |
| krs |
Posted: 2013-06-12, 15:27 Post subject: |
|
| I was thinking of something simpler as first step. For example, lets take kingdom overview window. It has a size, position, and some graphic resources positioned relative to that. Only with this info there will be no spectacular mods, but at least it is a start. (H2 look and feel would be possible for example, or battle log coming from top of the screen and initiative bar below, or some initiative bar border decoration). |
|
 |
| Ivan |
Posted: 2013-06-12, 15:11 Post subject: |
|
Because this was never discussed. It is still too early for that. For acceptable level of UI modding VCMI needs:
- at least some basic scripting support (execution of scripts on client + access into game structures)
- New functionality into UI to make it more flexible (e.g. concept of "events" instead of mandatory inheritance)
- Updating all ancient UI code to current standards.
My todo list is already too big and I doubt that someone else wants to add UI modding into his own endless todo-list :) |
|
 |
| krs |
Posted: 2013-06-12, 13:57 Post subject: |
|
| I have not found (and have to recognize neither searched too hard) any interface modding discussions. Is there anythings laid out already. Does anyone have a rough idea how it will look like? |
|
 |
| Ivan |
Posted: 2013-06-12, 00:02 Post subject: |
|
| Quote: | | ? You go to faction.json and you remove that creature's name. |
But what about doing this by another mod? This means that you need to replace entire "creatures" field, possibly making conflicts with other mods.
It won't be possible to have 2 mods that add creatures to same faction running at once.
| Quote: | | In my proposal you need to go to above factions.json, replace "monk" with "sharpshooter" and "monastery" with "wherever sharpshooters live". |
These two properties ("creature recruitable in town" and "creature belongs to town") are completely separate. Creature may belong to town but won't be recruitable (a lot of examples in H4) or vice versa.
| Quote: | | that is current behavior too so it does not count :). |
How? Currently you can specify "faction" only once in creature config. Duplicating entries in json will be detected on startup and removed.
You may replace this by another mod but this would give you dependency on this mod. Meaning correct load order where field will be always replaced by new mod.
| Quote: | | EG: duplicate creatures to different factions |
1) Creature can't belong to multiple factions. Engine just does not supports this.
2) Why you would need this? You may recruit "foreign" creatures in towns, you may give them to heroes. It only controls creature background and some bits of mechanics like "Units from X factions" morale bonus.
| Quote: | | So I think the discussion should go towards how to best model the modding system for real user needs and not towards how to make the most flexible modding system ever :). |
And what's most important - system must be easy to understand.
"Zen of Python" describes this quite well:
http://www.python.org/dev/peps/pep-0020/
Especially these two:
1) There should be one-- and preferably only one --obvious way to do it.
2) Now is better than never. Although never is often better than *right* now. |
|
 |
| krs |
Posted: 2013-06-11, 22:57 Post subject: |
|
| Quote: | Your proposition has downsides:
- there is no easy way to remove or add creature to/from faction. |
? You go to faction.json and you remove that creature's name. But here a more common scenario. Lets say you want to replace monk with sharpshooter. In my proposal you need to go to above factions.json, replace "monk" with "sharpshooter" and "monastery" with "wherever sharpshooters live". That's it! 2 strings replaced in 1! file and you replaced a unit in your faction. (Ok maybe you want to take a look at ingham too).
| Quote: | | - undefined behavior if creature is present in multiple factions | that is current behavior too so it does not count :).
| Quote: | | - more code to write. | Here is more about saving some time now, or loosing more time later.
Pharantesis: We and others are talking about stuff that would bring the whole modding system to its knees (EG: duplicate creatures to different factions). While the modding structure should be as flexible as possible, it should be built/improved with realistic use-cases in mind. So I think the discussion should go towards how to best model the modding system for real user needs and not towards how to make the most flexible modding system ever :). |
|
 |
| Ivan |
Posted: 2013-06-11, 21:38 Post subject: |
|
In most cases mod formats directly represent our internal structures.
So in this case creatures have "faction" field while factions don't have any connections to creatures. In fact there is no way to get what creatures belong to faction without iterating over all creatures checking "faction" field.
Your proposition has downsides:
- there is no easy way to remove or add creature to/from faction.
- undefined behavior if creature is present in multiple factions (not supported by engine and unlikely to change). Same problem with keeping both current and your system.
- more code to write. Current solution is just 1:1 mapping to our data structures. |
|
 |
| krs |
Posted: 2013-06-11, 17:49 Post subject: |
|
I still like my approach better :). Factions should have info about creatures, not the other way around.
Technically both ideas are the same, you just seem to want a factions file in every mod (creatures/heroes/dwelings/town) while I want a "main mod" that has ~ the same contents.
So in my approach you have a mod for factions (like above) and in that mod you specify what that faction consists of. |
|
 |