R.I.P Not responding.

You can get help here if Freeciv doesn't start on your computer, or if you keep getting fatal errors while playing etc.
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: R.I.P Not responding.

Post by cazfi »

We seem to have hard time understanding each other. Anyway, the only difference between "Always..." and "Auto..." is that latter is subject to buildability restrictions, of which extra.buildable=FALSE is one. You would want to start making a difference between different buildability restrictions? Some would affect "Auto..." and others not? It's currently documented simply as "...if the player can build it".

What do you envision to be the use-case for buildable=FALSE, or do you consider whole 'buildable' property of the extra unneeded?

Ruleset author provides tools for scenario author. Ruleset might be created for just one scenario (or set of scenarios), with very special location implemented by an unique extra.
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: R.I.P Not responding.

Post by cazfi »

You got a point in that both "AutoOnCityCenter" and buildable=FALSE are properties of an individual extra, and when buildable=FALSE "AutoOnCityCenter" does not have any effect whatsoever and ruleset author could as well leave it out -> we could consider ruleset author giving buildable=FALSE and "AutoOnCityCenter" simultaneously to have some other specific intention.
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post by nef »

The original problem was first mentioned in the civ1/civ2 forum]
Looking back at it I see that the main problem was that AGH and the client menu got all confused and to avoid this I proposed some additional Lua code. One could fix both AGH and the client (and perhaps they should be) but I could see no reason not to take the more obvious approach because there was no downside. As for providing another use for the dead combination, I would think that another flag would be the easier way to go - especially when you can leave AGH and the client as they are.

One particular benefit would be to remove the dependency on "build_time_factor = 0" as a means of preventing units building the extra (which is what I had to do). That is, you may some day want to implement unit activities that take zero time as it is for building cities. The generic buildable = False would then be the only way to stop unit activity (but at the same time allowing ...OnCityCenter - when wanted)
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: R.I.P Not responding.

Post by cazfi »

Now that I stumbled upon this thread, I've fixed a couple of the low-hanging fruits, but would it be time for you to report these issues to hostedredmine so that also we developers would be aware of them and they would not be forgotten to an obsburely named forum post?
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post by nef »

Now that I stumbled upon this thread,
My apologies. I had the impression that you read all new posts
I've fixed a couple of the low-hanging fruits,
Quite reasonable.

Initially I had a short list, but amongst those there were some issues that were quite substantial so I am not actually expecting them all to be fixed in the next double point release (fc2.6.1). As time went on I kept finding more - indeed, for quite a while as fast as I could redact them (i.e. "prepare for publication"). And I still have quite a few on my TODO list - but I presume you have plenty of work as it is.
but would it be time for you to report these issues to hostedredmine so that also we developers would be aware of them and they would not be forgotten to an obsburely named forum post?
To me this was a difficult decision right from the outset. I had already noticed similar comments by yourself (and JTN?), but I had a number of reasons for airing these issues here first.
nef wrote:I am reporting these problems here first for the following reasons:

A. These problems are obvious enough for all of them to be already ticketed. (Please comment)
B. This forum has higher visibilty to the community so others who experience these same problems will know that they are being dealt with.
C. Give others the opportunity to comment on the problems as they may, or may not, experience them.
Turns out (A.) was dead wrong (just 1 ticket that I know of).
I think (B.) is still correct but your comment about the obscure name may be a point since the entire thread was missed by at least one user. My defense (i) I'm still learning the ropes here, and (ii) I was of the opinion that if I kept all reports in the one thread then it should become known as "the place" for my reports.
(C.) also appears to have been of no particular importance.

But now there were also another reason that I missed out of the list:
(D.) I was (and still am) of the view that there should actually be gatekeepers for tickets. In part this is related to (B.) since I think most "high level" discussion should be done in the most accessible, user friendly medium (i.e. here), leaving the rather more linear commenting in HRM to technical discussions on patch code.

As for raising the tickets myself: initially I was thinking that this would be done in an orderly fashion by the (imagined) gatekeepers, but when it became increasingly obvious that this was not to be relied on, I came to the view that I would indeed have to raise some myself. So it was on my TODO list, but to be frank about this I got somewhat distracted by the civ1 ruleset. This was another case where I started out with just a few ideas, but as I was publishing them I kept coming up with more. This is still the case; I have still quite a lot in the pipeline (i.e. at various stages of development/redaction). My apparent (current) quiescence is deceptive - I have been at work on research.

It's been a matter of priorities. I sense that fc2.6.1 may be not that far off so I am trying to second guess as to what may be the best use of my time - but I have to admit that I am not as surefooted on this as I would like to be.

I would like to make one last comment:

(Almost) all of my posts so far can be classified:

I. Problem reports without code fixes (i.e. this thread and the new AI thread).
II. Problem reports with fixes (civ1/civ2).
III. Replies to reports by others - typically for enhancements but also actual problems.

So in fact it would be possible to use the features of this forum platform to search for not just the three threads listed above, but also ALL of my posts. If it would help, I could edit old posts to include the ticket number, either those raised by me, or by yourself etc.. Another possibility is to have one summary post containing matched pairs - item numbers and ticket numbers that someone (me?) could edit as new tickets are raised. Would include links to the original post and to the ticket. I may have made a mistake with civ1/civ2 in not numbering them but I could create some sort of checklist.
cazfi
Elite
Posts: 3077
Joined: Tue Jan 29, 2013 6:54 pm

Re: R.I.P Not responding.

Post by cazfi »

nef wrote:It's been a matter of priorities. I sense that fc2.6.1 may be not that far off so I am trying to second guess as to what may be the best use of my time - but I have to admit that I am not as surefooted on this as I would like to be.
I don't know your personal priorities, but have you considered taking a look at current 3.0 development for a change? The branch is fast approaching datafile format freeze and network protocol freeze, so it would be good to get knowledge about problems now rather than later. Often problems are much easier to fix before the freezes than with the restrictions set up by the freezes.

As for 2.6.1 timeline, I really don't know. Our release management is busy with matters not related to freeciv. IMO we already have enough content for making a release. I try to ease the situation by making at least those snapshot builds for windows users.
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post by nef »

42. Nukes and the GTK client.

The client stands too close to the nuke when it goes off - its electronic brain gets fried.

a. When in map view the client hides ALL city DB until you change to another tab.

b. A random selection of orders are denied until you have changed tabs (after which there is a new random selection). The selection applies to both kbd and menus. Existing orders appear to be unaffected.

Both (a.) and (b.) seem to be permanent damage (until save/restore).

Also:

c. Client is a bit garrulous about the destruction. In Civ I the nuke went boom and then silence, leaving you to clean up the mess. Fc gives a detailed damage report that you would think would only be available to the victim. Some of the data could be classified as intel leaks (and therefore a server problem).
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post by nef »

43. Barb predicates.

In the following list of rules all of them fail to change the value of the effect EXCEPT for the last (Empire_Size_*) which works 'as advertised'.

Code: Select all

[Not_Tech_Source_0]
type    = "Not_Tech_Source"
value   = 1
reqs =
{     "type",        "name",      "range",  "present"
      "NationGroup", "Barbarian", "Player", TRUE
}

[Not_Tech_Source_1]
type    = "Not_Tech_Source"
value   = 1
reqs =
{     "type",        "name",      "range",  "present"
      "Nation",      "Barbarian", "Player", TRUE
}

[Not_Tech_Source_2]
type    = "Not_Tech_Source"
value   = 1
reqs =
{     "type",        "name",      "range",  "present"
      "Nation",      "Pirate",    "Player", TRUE
}

[Output_Waste_0]
type    = "Output_Waste"
value   = 100
reqs =
{     "type",        "name",      "range"
      "OutputType",  "science",   "Local"
      "NationGroup", "Barbarian", "Player"
}

[effect_empire_size_base_test]
type    = "Empire_Size_Base"
value   = 20  ;  0
reqs    =
    { "type",        "name",        "range", "present"
      "NationGroup", "Barbarian",   "Player", TRUE
    } 
It seems to me that Not_Tech_Source is a reasonable use for the predicates used - that is, if not for this purpose then what?

N.B. For Empire_size_* the "present" value works as expected for both TRUE and FALSE.
Ignatus
Elite
Posts: 644
Joined: Mon Nov 06, 2017 12:05 pm
Location: St.Petersburg, Russia
Contact:

Re: R.I.P Not responding.

Post by Ignatus »

nef wrote:

Code: Select all

[Output_Waste_0]
type    = "Output_Waste"
value   = 100
reqs =
{     "type",        "name",      "range"
      "OutputType",  "science",   "Local"
      "NationGroup", "Barbarian", "Player"
}
This effect can not be checked in Lua since you have no way to suplly OutputType. Did you check in the game?

About Not_Tech_Source, they should work (but actually this effect only makes your diplos and city/king conquerors always fail to steal techs, did you test this or sth else)?
nef
Elite
Posts: 324
Joined: Mon Jun 25, 2018 5:01 pm

Re: R.I.P Not responding.

Post by nef »

This effect can not be checked in Lua since you have no way to suplly OutputType. Did you check in the game?
On this one I made an inference. The barbs continued with research at the same old rate. But you are correct, I actually checked Not_tech_Source in Lua as well as gameplay.
About Not_Tech_Source, they should work (but actually this effect only makes your diplos and city/king conquerors always fail to steal techs, did you test this or sth else)?
City conquest. Didn't tried diplos.
Post Reply