I would also like to broaden this suggestion to everything in the dependencies directory. Though we may still fall behind when we decide to not upgrade to a newer version when it arrives, this would be much more clear then when there happens to be a dependency directory with source.
Bertram {l Wrote}:I would also like to broaden this suggestion to everything in the dependencies directory. Though we may still fall behind when we decide to not upgrade to a newer version when it arrives, this would be much more clear then when there happens to be a dependency directory with source.
The other dependencies are mostly there to ease the development on Windows, I wouldn't remove them simply for that, and why not make CMake check their system version counter parts on linux, for instance.
I hope we can agree on that. Compiling OD on Windows isn't that easy.
The other dependencies are mostly there to ease the development on Windows
and why not make CMake check their system version counter parts on linux
We could even expect this archive to be unzipped into a certain location within our source tree and have CMake act accordingly when it finds the files, so the only extra effort to be done is to unzip a zipfile if your system cannot satisfy the dependencies.
Could you make a precise list of eye-hurting files so we can decide what to put in the zip file?
we can replace X with Y
As a first step, why not updating the used files and see if it is still working?
We can, but my problem is not so much with the packages themselves as it is the state they are in. The act of changing the source accordingly is not a trivial one.
I would consider this a good idea regardless of separation. Nevertheless, I would suggest someone who uses the windows platform to perform said changes, as they are the primary stakeholders regarding these files.
I would love to discuss configuration implications via text or voicechat with the person in question as it would make sense to change the directory to signify the different types of files we include. That is, assuming there are no more objections to externalising these dependencies.
Bertram {l Wrote}:True, so I'd suggest, let's do it, but just not now. After we've got a healthy release in the master branch, thus after the development branch is fitting our scope for the next release. Let's not do everything at once, right?
True as well. I'll do it since it seems I'm the one compiling there. Yet, would someone provide me the link where I can find dirent.h and pthreads, it'd be a time savior.
Btw, as I am a dungeon critter, and made out of pure evilish magic, I will recklessly and bluntly slaughter the tinygettext and tinyxml files there. We'll add proper replacement when we'll truely use them.
Sadly, I just don't have the time for that at the moment. Plus, what's written stays, and the forums are permitting me to look at what has been said weeks ago, which has proven being useful many times, and not only for this project. So, I'd rather have written-only communication, as for me.
I would like to observe that text-chat (e.g. irc) is also written
Bertram {l Wrote}:The campaign management, is for now and roughly speaking a set of pre-determined scenarios, thus a set of predetermined game mode (objectives, game, win/lose screen, new objectives, new game, ...) and this is something that will part of Event handling, IMHO.
As for assets management, I do think you're mixing the scripting language with the deharcoded config point. Something that we'll need of course.
But, I can't tell for now whether we'll be able to use scripts as config files, for instance. That's another debate.
As the for the choice of the scripting language. I'll be honest, I would avoid switching the scripting language unless AS proves it can't be used as a lib and/or for certain features.
As a first move, I'll upgrade the dependencies files and see how it turns. Then, I'd need your help to make the dependencies an outer zip file, and have options to use system-wide deps or not, and AS as a lib or not in CMake. Would you be ok with this?
May i ask whether these scenarios already include 'drop a group of heroes if keeper reaches X,Y' instances or are you talking more about selecting a map? The second sounds like something that fits within event handling, which I don't particularly consider a viable candidate for scripting. The former, however, seems to me to be a primary candidate.
I was not mixing them up, but i haven't considerated that idea you mentioned. This seems a very good idea. I have no idea though if there is more to adding model then could sanely be done in a config file. Perhaps a new thread to decide on this particular point is in order?
Despite the title i gave this thread, I see no problem with that course of action for the reasons you mentioned. To that effect I would like to focus this thread the question of where and how we want to use such a scripting language rather then a language shootout.
To that effect, in my previous post i mentioned a 'top' scripting language (what you get when pressing ~) and a 'bottom' scripting language currently in our codebase. Do you think it would be viable to have a scripting language (angelscript), with extra bindings, be the environment you get when pressing ~?
we can separate the zipfile creation from the system dependencies job. I would be happy to do the grunt of the cmake work and post a suggestion in an appropriate thread at that time.
Ah ok. we don't know each other very well yet, but for the record, please don't take any of my wrong assumptions as offenses.
It wasn't the case at all and it's actually great to be able to openly discuss all this.
The campaign stuff is only conceptual atm, (no actual working code so far). That said, I was speaking about it like a set of games to win in order to complete the campaign.
- A set of games can be part of a config campaign file.
- Events triggered within a game are more part of event handling, indeed.
--> De we agree about this?
Ok. Well, I'm not totally sure of anything at that point. Yet, from experience, I'd say that the console top "language" should stay very primitive with a defined set of statements. (Easier for user, easier for us to prevent mistakes from them.).
Now, I can see how good it is to be able to run AS stuff from the console, and if I understood you correctly, we should add some kind of "script <AS code>" command that is permitting us to run raw AS code from the console for game debugging purpose. Did I get the idea correctly?
To be sure about it, stuff like '30 minutes in the game the keeper gets a prescripted warning', 'if any keeper claims the tile at 294x102, these six heroes drop on these predefined locations', would be handled with the event handler? If so I think we are in agreement.
If we come to the conclusion we want to have a very simple top level scripting language, I would personally be against such a command. Reason is that this would bascially invalidate the simplicity of the console, as we still need to account for whatever angelscript is going to do. It may make sense in a debugging build for purposes you described, but I would protest having it enabled in the release builds.
I would like to propose to elevate angelscript from the position of implementing the console language, to being the console language, since it is entirely viable to have a powerful scripting language which also allows simple commands.
It's also a fine and simpler solution as long as we can prevent running AS commands that breaks the game/system
To this i would suggest we define a list of 'safe' functions, the effect of which we test; and tell users to keep to that set if they do not want to break things.
Nevertheless, we would still like to minimise the effect the user facing interpreter has on the game itself. To this effect I suggest we let it run in its own little process, away from the rest of opendungeons, and only allow it to fetch/send data to opendungeons through predefined functions.
These predefined functions may still allow the user to do bad things to opendungeons, depending on ones definitions, but this would save the genius who creates an endless loop in angelscript or corrupts angelscripts state. In order to even give him back his console after creating such, i suggest we allow the ability to kill that interpreter and restart it.
(for example, two passive 'stealth'keepers just next door suddenly turn into agressive 'war'keepers for some in-game reason, or at some predefined moment "What?! Heroes broke though inpenetratable wall! Be sure to capture those dwarves alive, keeper; they may have invaluable information.")
On another tangent, if I am not mistaken, the current targets for scripting are: AI, Game Event handling, GUI handling, and Objectives, console, tests/debugging. Do you happen to know the general state of these parts of the game are? I am still in the beginning phase of understanding the codebase and knowing the current situation makes it easier to decide on a target.
Bertram {l Wrote}:Good point. I even wonder whether we could add a parser that makes the console refuse to trigger anything else than those functions when not in debug mode.
Sounds fair. I don't know AS enough yet, but if we can create a binding instance at console opening and delete it at console closing, whatever happened here, it might be a good start.
AFAIK, I've seen AS use only for the console. I might be wrong though. I think we both agree about the core logic behind the use of AS. And try and put some sequential task list here, I'd suggest we start on the AI, since it would make OD have a better gameplay right now, and since an objective system, and a game event manager are still to be created.
Hrm... I'm not sure. Essentially, I think this would involve wrapping around the interpreter again; re-creating the top-layer language. It could get especially hairy if you still want to allow parts of angelscript. My original intention was to unceremoniously close bugreports made about using 'nonsafe' functions as 'wontfix', but still allow people to play around with it, possibly creating extensive opendungeons mods.
Creature AI - already exists for the most part in c; doesn't need to be scripted in my humble opinion, but I wanted to mention this ai separately.
Player AI - basically, non-player keepers and hero 'keepers'. They need at least the same access as the player keeper (spells, commands, stuffs like that), though traditionally the computer is a cheating bastard with way more access then you. I suggest we implement only the access which is required for them and let ai writers think up their own angelscripts on how when to do something, whilst not being cheating bastards (perhaps we want to make an exception for at least posession though).
If you're planning to close bug reports due to mis-use, it means the solution has got flaws, already on the design level. Or, we can simply warn users the console is a development component and shouldn't be used by regular users?
Hmm, nope. Adding bindings won't be sufficient.
As for objectives, I'd say met Objectives should trigger an event. Would it be a win event, or a something-bad-happened-and-objectives-have-changed event.
There is also something important here. IMHO, a new more appealing objectives window should be made, and shown at game start (with why not a short description of the scenario and the map name).
I'd personally remove the objective small window bottom-right and move that into this window, that you could open using a button.
As for events, in Valyria Tear, there is a quite complete event manager, and basically, it's a manager that check a pile of events continously.
Creating the manager is the first step, but we should try to add event types little by little and not now.
There is IMHO, enough to do on the table before that.
It has flaws, yes; as does any design decision. I think the warning would be a good idea, and is also in line with my intentions. The primary use of the command line for non-modder/coder people I think would be fix accidental unwinnable situations or jammed objectives (which should be fixed in-source afterwards). I don't think these kind of people deserve a talking to about using the console when asking support afterwards.
The kind of bugs I was thinking of was where someone has upgraded the mages' basic fireball to way-beyond-game-levels genocide-the-board level, and then complain about bodies get stuck in the wall from the blast (due to the physics engine not forseeing such speeds of acceleration or whatever).
The actual coding would be incremental, but i do not think it is bad to consider a list of likely ways we want to engage the event manager. It would be sad to implement a great and wonderful time-based event manager, only to realise next we need to completely rebuild it in order to also trigger based on your gold count.
datastructures would be on my agenda in terms of code before scripting even. Yet, that doesn't leave out the possibility to gather ideas about this subject in advance so that when we get to that point, we already have a clear view of what we would like to ultimately achieve with these components. Whilst I am all for an agile approach in implementing features, talk is a lot cheaper then code and a lot of value can still be gained by having well thought out design ideas.
Users browsing this forum: No registered users and 1 guest