News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

constraint 'class'

Started by leopard, May 15, 2009, 09:18:42 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

leopard

following on from thoughts about goods vehicles

constraint 'classes' so you can specify exact vehicles as at present.

or could specify a 'class' e.g. "passenger-brake", "goods-brake", "fitted-goods", "unfitted-goods", "fitted passenger" etc

essentially defining the type of physical coupler present, as well as providing a way to state that freight vehicles need a brake van at the end (for early vehicles) but not bothering about the type.

thus a freight vehicle can be set to require either any other freight vehicle or a brake van, without having to specify every possible combination as at present.
My Simutrans on the apple mac homepage http://www.aleopardstail.com/simutrans/Index.html

The Hood

nice idea - no idea how easy this would be to code, but I would definitely use it in pakBritain if implemented!

leopard

pakritain is where the basic idea came from, was thinking about this a while back when I did my original somewhat cartoon like voyager. needed to do five vehicles, specifically so you could have a four or five car. but no more.

later thought more about it as a way of requiring brake vehicles for some types of stock. the 'logic' of a braking system could be vastly more complex, but while adding reality wouldn't add much to the game play (i.e. adding a brake force calculation).

but its a good way of ensuring something with three link only connects to three link, instanter to instantor, screw to screw, knuckle to knuckle etc.

e.g. you could define many types and colours of MkIII coach, all basically defined as a MkIIIb HST stock vehcile, a Cl43 powercar can connect to any of them, and they connect to each other, without the huge constraints file, and needing to update it whenever a new graphic goes in. but these vehicles are then locked out from anything else

likewsie MkIV stock only ends up behind a Cl91

some goods stock only behind a Cl66, and the Cl66 itself only able to haul certain types of wagon etc.

plus it makes it a little harder to put a Cl66 in front of a massive rake of older (cheaper) freight stock where in practice it would probably pull the first vehicle apart.

thinking the easiest way would proabbly be to add wildcards to the constrain system, e.g. you require the next vehcile to match a pattern: MKIIIb* or TL* (three link)

this may be easier than changing the code in a more detailed fashion, essentially add the '?' and '*' wildcards. specifically since this shouldn't effect the current pak files at all, but offers options for newer ones
My Simutrans on the apple mac homepage http://www.aleopardstail.com/simutrans/Index.html

jamespetts

This actually makes a great deal more sense than the present system, which becomes difficult to maintain if it is used in any serious way. When I first saw the feature in Simutrans, I thought that that was how it was done, because that is the logical way of doing it. The easiest implementation would simply to be to define constraint categories, and anything that has any given category can couple to anything else with that category. Anything with no category could not couple to anything at all (so most road vehicles, for example, would simply be given no category). Each .dat file would have something like "coupling_constraints=1,3,5,9" (etc.).

Defining wildcards would be rather harder, unfortunately, since Simutrans-Standard does not have much in the way of string manipulation classes.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

VS

#4
Anyone is welcome to look at the reference mess dragon and slay it :) The problem is quite broad. Afaict:

1) Vehicles have this veh_besch class (don't remember exact names) that stores the data for a particular vehicle type - you create an instance of it and fill in gear, speed, images etc. Besch in simutrans code always means this - type base storage.

2) Then you have a vehicle class instance with the unique data (name, id, what is loaded, position, actual speed...) and know what is its type from having a reference to its corresponding besch. It is like, having one template and inherit actual vehicle instances from it - except not in "OOP domain", but "vehicle domain". (Does it make sense?)

3) Besch instances are stored once per item type; no data duplication, everything else is just reference to them.

4) Constraints are done by storing an array of besch references as children of the vehicle besch. In a quite ugly untyped array or something like that, might I add... on one heap with image references and everything, you must look only at particular index ranges!

5) Constraints are checked by asking the queried "partner" for its base type besch and then comparing its equality (iirc pointer-wise, possible because of #3) to the besches stored in "our own" besch's constraints.

6) Makeobj stores constraints as children nodes of vehicle types!

7) Loading has some more phases when first are (probably) resolved vehicle besches from names to ids (indices in some global vector) and then once again the constraints resolved to besches as well. This includes some really ugly and complicated relations.


So! Now you can (hopefully) see that having a "vehicle class" spanning across multiple besches would require cleanroom implementation of the whole system, as you can't really get a single reference to everything of one "vehicle class", can you. Same goes for substring matching and any other magic on vehicle type names. Strings don't matter, it's all reduced to pointers 1:1.

I am not prissi or Hajo, so I can't really say much about why or how, or more importantly what now. One thing that strikes me as particularly ugly is the untyped array of "children" that have really no connection except ownership (see get_kind() and where it is used) and I would never write that.

Unrelated to this, the idea of storing and comparing pointers instead of names is wickedly clever and beautiful and probably saves some memory but very limiting. On the other hand one might also ask, how much memory is really saved? A few strings per besch, as opposed to per vehicle instance where it would have mattered? If the hypothetical new implementation went the other way and added to current system, extending reference search to insert more actual pointers in place of "class" constraint, how many references would be inserted in place of one? Would it still outweigh using strings?

Keywords when starting to look at code: besch, xref.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

jamespetts

An untyped array of pointers? That is not good design. That is painfully unmaintainable. My suggestion on coupling constraints would be quite easy to implement: each vehicle besch would have a 16-bit variable, which would hold (using bitwise operations similar to those used for Simutrans-Experimental's way constraints) 16 boolean flags. For each check on whether the vehicles could couple, a bitwise AND would be performed to check whether there are any matching constraint bits: if there are, the vehicles can couple; if not, they cannot.

There would be a second boolean variable in each vehicle besch file, called "can_be_rear". The default would be true. If that was set to false, however, the convoy would not be drivable with that vehicle in the rear. That would give the same functionality as the current system, but with far less unmaintainability, overhead, and non-OO pain. The interface to the user would be identical to what it is now.

The real problem with that approach, however, is what to do with existing paksets that use the current approach. Backwards compatibility would be a very difficult problem to surmount.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

The Hood

OK I've thought of a simpler solution - not as good admittedly but it will work better than current.

We have: Constraint[Next][0]=none
i.e. forcing this to be the last vehicle in a convoy

Can we have: Constraint[Next][0]=anything
i.e. forcing this to have another vehicle (any vehicle of player's choosing) in the convoy?

This would greatly help implementation of brake vans in pakBritain...


VS

That's when you put no constraints.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Michael 'Cruzer'

Quote from: The Hood on June 03, 2009, 06:10:26 PM
OK I've thought of a simpler solution - not as good admittedly but it will work better than current.

We have: Constraint[Next][0]=none
i.e. forcing this to be the last vehicle in a convoy

Can we have: Constraint[Next][0]=anything
i.e. forcing this to have another vehicle (any vehicle of player's choosing) in the convoy?

This would greatly help implementation of brake vans in pakBritain...

You already could write this!
You only have to write: "Constraint[Next][1]=anything" and there should be no "Constraint[Next][0]", because if there is any 0 simutrans don't look at 1 and so anything is okay.
It would be the same effect ;)
Founder and Ex-Maintainer of pak192.comic. Provider of Simutrans Hosting rental service.

jamespetts

I think what The Hood might mean is that constraint[Next][0]=anything would over-ride a list of constraint[Previous][X]somethings in other vehicles; is that right?

The difficulty is that, if one wants to have, as in The Hood's example, a brake van that must be at the end of a train of a large number of different sorts of wagons but can connect to anything (more or less) itself, that would involve each individual wagon having to specify that behind it can be coupled any of a very long list of other sorts of wagons (as not all goods trains carry only one type of freight) plus the brake van. That long list becomes unmaintainable. So, if the individual goods vehicles were able to over-ride rearward constraints with their own forward anti-constraint, the need to maintain the unmanagable list would be gone.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

The Hood

OK, what I wrote was confusing.

It's not quite the same as no constraints VS: Currently if you have no constraints, that vehicle can be the end of a convoy OR you can stick another vehicle on after it.  What I intend with my Constraint[Next][0]=anything is that it would force the convoy to have another vehicle after that one, i.e. vehicle with the constraint cannot be the end of the convoy, but anything else can go after it (anything = anything but not nothing).

If my understanding is correct, Cruzer's suggestion doesn't get round that issue (correct me if wrong!).  As for forward anti-constraints, I think that has the potential to cause mass confusion...!!!

I hope it's clearer now what I'm proposing?

jamespetts

Ahh, yes, The Hood's actual idea is far more useful than the idea that I thought that he had.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

Did you try cruzers suggestion. At least he develops pak192, so this may work.

jamespetts

Prissi,

ahh, no, I think that what The Hood meant was that he wanted to allow any vehicle to couple to the rear of specified vehicles, but not allow that vehicle to be at the back of a convoy. That isn't possible with Cruzer's suggestion, is it?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

The Hood

I don't think it does, but I'll investigate later (unless someone can provide a definitive answer in the next few hours?)

Michael 'Cruzer'

#15
Quote from: The Hood on June 04, 2009, 07:28:28 AM
OK, what I wrote was confusing.

It's not quite the same as no constraints VS: Currently if you have no constraints, that vehicle can be the end of a convoy OR you can stick another vehicle on after it.
What I intend with my Constraint[Next][0]=anything is that it would force the convoy to have another vehicle after that one, i.e. vehicle with the constraint cannot be the end of the convoy, but anything else can go after it (anything = anything but not nothing).

If my understanding is correct, Cruzer's suggestion doesn't get round that issue (correct me if wrong!).  As for forward anti-constraints, I think that has the potential to cause mass confusion...!!!

I hope it's clearer now what I'm proposing?

Sorry Hood, I miss understand you. I thougt you want to have a constraint-value which has the same effect that no constraint. So my sugesstion also don't work for your need.
But I fully support your idea, but anything isn't the right word for it, because I get a little bit confused with it.

Instead fo "anything" probably you could use: "notNone" (or a more C like: "!none") or "notAtTop"
I would prefer "!none"
Founder and Ex-Maintainer of pak192.comic. Provider of Simutrans Hosting rental service.

The Hood

I can confirm that Cruzer's suggestion doesn't do it (as we thought).  So can I ask again for the "NotNone" constraint to be added as an extension request?  I don't mind what it is called, anything, notnone, !none, whatever, you can even have it in German (or Swahili for what it matters as long as it works) :)

jamespetts

For what it is worth, I support The Hood's request and also agree with Michael's syntax suggestion :-)
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.