While dwelling in the engine code, I stumble upon imo obsolete functions. Since I don't know my way around the engine, and if they are perhaps very important after all, I'll post them here and request for comments/advice whether they can be deleted.
C4Object::BuyEnergy() - refills Clonks energy inside bases for a reasonable price
C4Object::ExecBase() - apparently removes the snow on the base
I'll post more over the time.
C4Object::BuyEnergy() - refills Clonks energy inside bases for a reasonable price
C4Object::ExecBase() - apparently removes the snow on the base
I'll post more over the time.
> C4Object::ExecBase() - apparently removes the snow on the base
I already removed everything else that function did, because that has been reimplemented in script. Snow-removal is probably best kept in the engine for performance reasons, so there's nothing to do here anymore, except possibly renaming the function.
> C4Object::BuyEnergy()
That function is already gone, in the same commit as the above.
C4Object.cpp
along with NeedEnergy
2336 // Energy shortage
2337 if (NeedEnergy) if (::Game.iTick35>12) if (eDrawMode!=ODM_BaseOnly)
2338 {
2339 C4Facet &fctEnergy = ::GraphicsResource.fctEnergy;
2340 int32_t tx=cox+Shape.Wdt/2-fctEnergy.Wdt/2, ty=coy-fctEnergy.Hgt-5;
2341 fctEnergy.Draw(cgo.Surface,cgo.X+tx,cgo.Y+ty);
2342 }
along with NeedEnergy
This draws the red lightning symbol above the object when it's out of energy.
Actually: There is far more to remove if the energy system gets completely replaced by Maikels. Question is, of how much should be still left of it.
That depends on how the Command system will look in the future, at the moment the Energy command is completely broken. Things that can at least be removed are the OCFs and C4Ds related to power but not to lines. ObjectComDigDouble and ObjectComLineConstruction should probably be reimplemented in C4Script, and are obsolete as such. C4Player::PlaceReadyBase is broken, but do we need this in the future. And the command Build is partly broken since it depends on Energy. And probably something I missed.
>removed are the OCFs
Why are the OCFs not used instead of the functions "IsPowerConsumer return 1"?
>C4Ds
Are there any?
>ObjectComDigDouble and ObjectComLineConstruction
>C4Player::PlaceReadyBase
What are these used for?
----
and I am also talking about the act map entry "energyusage" and the related checks in the engine. Plus all this energy management for structures.
OCFs are based on LineConnect C4Ds, and these are specified in the Defcore. If one makes a new building only including the power consumer would not be enough, one would need additional defcore changes. I don't know what is prefered, keeping the OCFs or not.
The first is what happens on double dig with a clonk, i.e. Activate calls in the first held object, Checking for trees, Checking for linekits to be disconnected, Activate call inside the clonk itself. Line construction handles linekit connection, i.e. power lines, drain and source pipes, although this is never called in praxis.
PlaceReadyBase is used to generate the base when you select multiple buildings in scenario.txt, it also includes powerline connection.
Seems to be obsolete.
>>ObjectComDigDouble and ObjectComLineConstruction
>>C4Player::PlaceReadyBase
>What are these used for?
The first is what happens on double dig with a clonk, i.e. Activate calls in the first held object, Checking for trees, Checking for linekits to be disconnected, Activate call inside the clonk itself. Line construction handles linekit connection, i.e. power lines, drain and source pipes, although this is never called in praxis.
PlaceReadyBase is used to generate the base when you select multiple buildings in scenario.txt, it also includes powerline connection.
>and I am also talking about the act map entry "energyusage" and the related checks in the engine. Plus all this energy management for structures.
Seems to be obsolete.
No need for a new thread. I removed GetTaggedPlayerName from the engine, and reimplemented it in C4Script. Also extended it and the already available GetPlayerByName to Teams. I hope I exported it right. Would be useful if someone could test/commit it.
ISC licence is understood.
ISC licence is understood.
Attachment: TaggedPlayer.patch (8k)
I don't think this is a change that might cause problems on different systems. If it works for you, we don't need to review it again. If you extended the functions it'd be good to update the docs as well.
> I hereby license the following file(s) under the CC-by license
Since this is the blanket statement the forum adds, I'd like to have this clarified: Is this patch CC-by or ISC (furthermore, what's our preferred license for scripts)?
We could change the statement to
I hereby license the following file(s) under the CC-by license for artwork or the ISC license for scripts
I hereby license the following file(s) under the CC-by license for artwork or the ISC license for scripts
HomebaseMaterial-stuff after script base functionality has been tested.
The whole FIGHT-procedure and all the stuff that belongs to it (probably commands, FIGHT logic, actions etc.)
Message without an object parameter - For important things dialog boxes are the prettier option, and anything that's not important does not need to be a global message.
I've implemented this. We're getting close to a critical mass of game content where incompatible script changes aren't easy to deploy anymore. Well, I guess that's good for the game...
http://bitbucket.org/guenther/openclonk/changeset/ad89db429c5d
I'd appreciate reviews and/or tests.
http://bitbucket.org/guenther/openclonk/changeset/ad89db429c5d
I'd appreciate reviews and/or tests.
Actually, I'd rather see CustomMessage renamed to Message and all other Message functions removed. Having so many message functions with different parameter sets just sucks.
Well, that's more work than I want to do at the moment. Also, CustomMessage would need to be fixed so that the default behaviour would be to display the message to either all players or the owner of the object, instead of player one.
Actually, that's a common problem. And it's something I'd rather fix by changing NO_OWNER to 0 and let player numbers start at 1.
If you're about it: Make
GetID()
obsolete and disallow reuse of player numbers.
What about the Messages in the "Guardians of the Windmill" scenario?
Anything to do with settlement scores can be removed from the engine, since it is not displayed in the hud anymore. It is also easy to reimplement with C4Script. It still appears in the evaluation after the game.
I think we could keep the score fields, but remove automatic engine counting of objects, etc.
Then objects/scenarios can still use the score, but do it on a more meaningful basis. For example, goal objects could give you score based on the difficulty of the goal.
Then objects/scenarios can still use the score, but do it on a more meaningful basis. For example, goal objects could give you score based on the difficulty of the goal.
All those backwards-compatibility options for landscapes in the Scenario.txt. We might need them again, but at the moment, we only need one format for the landscape.bmp.
Bitmap fonts. Did any scenario actually use them? The font stuff could be nicely simplified if it only had to worry about vector fonts. And bitmap fonts probably got broken in the Unicode transition anyway.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill