
I've set up a design document including most of what I or other people have written in my threads 'A brief history of resources' I & II as well as some scattered ideas which I gathered around in the forum.
Here it is! The Settlement Design Document.
Most of what I intend to do is written there. I know that there are other ideas but since the overall support in the mentioned threads was very positive, I hope to find some people around here interested in implementing what is in the document to obtain a proper settlement basis.
And just in case: I am aware of this page in the Wiki (Settlement Concept by PeterW) but the intention given there so far is different.
This thread is to manage the development. The todo list is in the document. We need scripting, designing and modeling!
If the thread becomes too confusing I might consider another way of showing Who's working on what.


Renaming it won't be a problem, I think.

> I'm right now searching for a team [...]
It's great to see that finally someone takes the lead of settlement implementation! I think quickly motivated people will be found amongst the old OpenClonk team who jump right on board with you. After all, settlement development was frozen far too long, now lets make nails with heads!
I myself will try to help and advice as far as I can but right now, I want to limit myself to the engine side and administration of the website. When I have time to contribute something to the settlement, I now at least know whom to talk to :-)
> The default branch of the repository is under a feature freeze
Release today.

>I think quickly motivated people will be found...
Like me!
i would like to join the developers.
My favorite is scripting for CR, but i think developing OC will be fun, too.
My time is limited, but i will do what i can!
Right now i work on an update of one of my CR Projects, the agriculture extension package.
http://www.ccan.de/cgi-bin/ccan/ccan-view.pl?a=view&i=5923
I know the problems of the CR Plant and Harvesting system, and also the Problem of limited component options. (and CRs limited IDSpace...)
I'm German so my English is not my default language...


Please continue using devel branch until it's clear that is does not interfere with a whatsoever planned bugfix release.

Producer library - Maikel
Please see to leave a quick note if you currently develop something from the DD.


Has the "but I like to connect buildings with linekit"-fraktion been overruled?
My stance is that we should use lines for something more awesome, like mechanisms. Make players wire up their drawbridges - at least that has interesting applications.

If the change turns out to make the game more boring, reverting it will not be the problem.

It should exist only one type of liquidpipe (not both source and drainpipe). And an engine/default function for liquid transportation.
The pump pumps liquid into the pipe and the structure connected gets an LiquidInput(int dMat, ind dAmount, object pSource, object pPipe) call
maybe there could be a function like LiquidOutput to. So structures can decide whether pumps can put liquids in or out.
Link:
http://forum.openclonk.org/topic_show.pl?tid=853

I tried to change the pipe system.
How the mat is transported and which calls are made.
Pump->Timer()
#SourcePipe->GetLiquid(int dnMat, int dnMaxAmount, object pPump)
##SourceObject->LiquidOutput(int dnMat, int dnMaxAmount, object pPump, object pPipe)
#TargetPipe->PutLiquid(int dnMat, int dnMaxAmount, object pPump)
##TargetObject->LiquidInput(int dnMat, int dnMaxAmount, object pPump, object pPipe)
So you can reroute/specify/block liquid flow, like you can block clonks enter a building because they are hostile.
Non of these objects should change something in another (only via funccalls)
the old system somewhere someobject decides which barrel to fill in the liquids in the targetbuilding. Thats stupid. ObjectExtractLiquid...




Development of the settlement ceased! I blame myself for being almost unavailable.
I won't sum up the things done so far. I brought the DD up to date, crossed out everything that has been done. But I saw the need to describe the serious tasks waiting for us.
What are we waiting for?
According to the order in the DD:
1. Libraries
Producer is half-way done, lacks the polishing and some minor stuff. But it's okay to implement and test the buildings, future changes won't affect them much.
Workshop isn't touched. It's not that much of a difference from the producer and won't take long when needed.
Testing has been shown that the producer is fine to the point we can make it. Saying that we are reaching the boundaries here. There is no way of proper item/contents handling. The old engine menus are somewhat useless, there is no way to properly interact with the contents of a building (checking, getting; just putting via collection zones is fine). On the side of the people how contributed to the settlement development so far, there is no one (as far as I know) who is able to do anything that comes near the engine changes that are needed for the menu handling concepts.
All we can do is hack our way through the old or the ring menus to get something that works for further testing. So what I want to do right here and right now is to set the ball rolling: Someone take up the menus, OC will need them in the future! Or resume discussion on this if needed.
2. Buildings
The main task in buildings were and are graphics! Ringwaul did some awesome fast jobs on this, providing us with all we have now. But there is more:
- Concepting & modeling for: Armory, Chemical Lab, "Spinning Wheel / Weaving Loom", Inventor's Lab, Shipyard.
- Finishing & texturing for the kitchen: http://forum.openclonk.org/topic_show.pl?tid=875
5 buildings from scratch and "that's it"! (until energy is needed.. ;) )
3. Items
Mainly to do: Cotton, Cloth.
Grenade Launcher and Mechanism are second-rank. Still there is confusion about the mechanism (theory needed on this hasn't been resolve; I have a mere idea on this but nothing of the mentioned tasks comes near something that's in the game right now; like connecting levers and doors).
4. Plants
Ringwaul had some first impression on the big mushrooms but there still missing graphics!
Cotton is untouched.
I have a half finished moss lying around. Scripting's okay and I'll do it, graphic is missing.
5. Material
Second-rank. Crystal is in discussion.
6. Interdisciplinary Connections
I should rather call this 'interdisciplinary disconnections' because that's what they are! As written above, menus are total waste land.
There are ideas on buying/selling but without menus it's pointless. The flagpole is somewhat buggy. I'll see to catch Zapper sometime and ask him if the flag library contains all what is should contain or if there are missing parts (if you read this, Zapper, you might want to write something about this).

>The flagpole is somewhat buggy. I'll see to catch Zapper sometime and ask him if the flag library contains all what is should contain or if there are missing parts (if you read this, Zapper, you might want to write something about this).
There are missing parts - namely the auto-selling of gold and the power-chain integration.
But other than that. What bugs do you mean? Anything related to the ownership thing? I must admit that I did not test that properly back then

I made a quick test with the flag and there are a few things that I recognised. First of all wasn't the flag supposed to be self-constructing (what about deconstructing)? And the markers appear in Construction() but I think Initiliaze() might be better? (just a minor thing of course).
The colour was somewhat broken. The markers had the right one, the flag didn't. The area from my flag clipped with one from NO_OWNER flags.
I tried to fix something but I didn't know what to make out of the global flag array. I first wanted to ask why it is necessary before touching anything.

>First of all wasn't the flag supposed to be self-constructing (what about deconstructing)?
Mh, I didn't really care for the construction, since I thought there would be a construction library at some point that would care for anything related - should the flag really behave differently from other structures?
>And the markers appear in Construction() but I think Initiliaze() might be better? (just a minor thing of course).
Mh, true. Initialize() should be called at 100% construction - not Construction() - my mistake :)
>The colour was somewhat broken. The markers had the right one, the flag didn't
Mh, I guess that's because I didn't have graphics for the flag back then
>The area from my flag clipped with one from NO_OWNER flags.
Interesting point. How should NO_OWNER flags behave? Should they still keep their influence (no-owner-controlled-village) or should they act as if they were not there?
>I first wanted to ask why it is necessary before touching anything.
For optimization purposes. Especially for the parts for the power system.
It might be unnecessary if the engine knows what objects of a definition (/children of a proplist?) are existent at the moment and FindObject2(Find_ID()) is optimized in that direction (is that so?)
>Can you say a word or two about the two topics mentioned?
The auto-selling would be pretty straight forward. The current idea was (when gold is the only object that can be traded directly (/without something like a trading outpost etc)) to have gold be auto-sold in close proximity to a flag (with a nice effect and some floating dollar signs or something like that.. :) )
The current plan for the power-chains would be that linked flags (linked by area intersection/touch) would count as "one base" where the energy could be transfered between buildings "wirelessly". (Producer buildings would "connect" to such a "base" and consumer buildings would request power)
I already started the work on the power stuff. So if you want to do something there, I could give you what I currently have (not much - mostly the definition of "linked flags")
> should the flag really behave differently from other structures?
Well, depends on how you want other structures to construct. Isn't it different already as it doesn't require a hammer to hoist?
> Should they still keep their influence (no-owner-controlled-village) or should they act as if they were not there?
A village is no-owner-controlled by default, isn't it? :)
Hm. Keeping neutral flags might be a nice way to block players from claiming a certain space though?

> Isn't it different already as it doesn't require a hammer to hoist?
So far, it does because we don't have a flag object to carry around ;)

> Mh, I didn't really care for the construction, since I thought there would be a construction library at some point that would care for anything related - should the flag really behave differently from other structures?
I don't know. I just read this. I'm not up to date in case of any discussions. As well when it comes to:
> How should NO_OWNER flags behave?
It just felt wrong that their area was included into mine.



>until energy is needed.. ;)
Do we have the same function for energy (DoEnergy) like in CR?
It was quite anoying that we have the same function for healing (livings) and energy (structures)
what if someone wants to "charge" a (living) giant with energy?
Maybe we should rename it to health and use that as default for every object
so we don't need any Damage(....) {if (GetDamage()>100) Incinerate(); } Callbacks
In CR i wrote a medieval ram and i had to write this callback for every structure.


>Development of the settlement ceased! I blame myself for being almost unavailable.
I've also not had much time recently; real life has become a pain in the ass.
But all in all I think this point is not slowing down any further progress on settlement anymore.

Btw: How was Malta?

IsItemContainer
(for global CreateContentsMenu
-function) and the forward calls to the menu.There are effect callbacks for the normal engine calls??
Malta was cool, I could show you some pictures sometime this week. :-)
>Malta was cool, I could show you some pictures sometime this week. :-)
Sounds good
>My suggestion was to implement a small library Item_Container that contains IsItemContainer (for global CreateContentsMenu-function) and the forward calls to the menu.
Since it currently works (don't know how good, cause I didn't tested it "extensively", only some multiplayer rounds), I want to invest my time first in implementing some features for the other menus.
>There are effect callbacks for the normal engine calls??
No the effect just checks every frame if the contents have changed.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill