Posts by Miwarre

As Player.getAttribute() and Player.setAttribute() expect a String, providing them with a String fixes the compiler complains. This alone will not fix the run issue of firstly setting the attribute to an int and then retrieving it as a generic Object.

The compiler does not complains about the statement

Object test = player.getAttribute(testattribute);

as it is syntactically correct, but you will be able to do almost nothing with the test Object you get back. Depending on what you are going to use it for, you will need to cast to it to something else, most likely (unless you are trying something very fancy!) to the same type you initially set it to, i.e. an int.

Quote from zfoxfire

I just don't understand why as a developer of a new game that you would choose DirectX over OpenGL. Does one have a steeper learning curve?

I stopped dealing with DirectX at DirectX 9 times. Anyway, while OpenGL only deals with graphics, DirectX also deals with sound and other goodies, so I understand it might be quicker to gain proficiency in it alone than in OpenGL + OpenAL + ...

Also, OpenGL might be seen as somewhat more low level than DirectX, with more to do by yourself.

Anyway, I think very few today dev teams use either architecture directly; most use some higher level framework (as RW itself, which uses OpenGL by way of LWJGL through JMonkey), the programming language they are more familiar with also being part of the landscape.

Quote from joni909

if you're a linux user
witch linux do you use i've tried many and are recently trying kubuntus

Linux Mint (now at 17.3) here with very plain Mate desktop, after a false start with OpenSUSE several years ago and an attempt at Ubuntu (Unity :evil: vade retro!).

First of all the variable testattribute needs to exist. So, somewhere before using it, it should be defined.

Second, the prototype of the method in the API is: getAttribute(java.lang.String key); so the testattribute variable HAS to be a String; in summary, somewhere you have to put a statement like:

String testattribute = "SomeFancyAttributeName";

Third: when you set the attribute, you set it to an int; when you retrieve it, you need to cast it back to an int:

int test = (int) player.getAttribute(testattribute);

or maybe to Integer (I am quoting by memory, so I cannot test it):

int test = (Integer) player.getAttribute(testattribute);

Try these changes and tell us how is going.

I checked the Steam page (tired of keep confusing this off-topic thread with my off-off-topic musings): alas, another Windows-only game... once of these days I'll have to give up and try WinE, assuming these kind of games run decently enough in it...

Quote from diegomarino80gongo

congrats miwarre, i suppose you are german. german speaks latin better than italian

Thanks, I am actually Italian, but I take this as a compliment! I studied Latin for 8 years at the school (old "Scuola Media"..., which speaks about my age), for another 4 years at the University, I have a degree in Latin Palaeography, and I have messed with Latin since (to eventually end up as a programmer, go figure!), so I was a bit struck by the ungrammaticality.

Quote from zfoxfire

huh... so novus is masculine and inceptio is feminine? I have to wonder if that's intentional if it is gramatically incorrect.

Yes, novus is masculine and inceptio is feminine. It might be intentional (while I cannot see how) or it might be a 'confusion' with the Novus ordo seclorum motto appearing in the verso of the Great Seal of the U.S.. The motto is in itself peculiar for the adoption of the medieval orthography seclorum in stead of the classical sæculorum.

I am converting TELevator right now, but I am kind of stuck for the lack of those methods.

I have to admit I ever heard of it. But such a blatant error in the Latin name (inceptio is feminine and the adjective should then be nova) would not inspire me much trust...

Thanks, @Deirdre, for your reply but I do not really understand it.

Those methods are not "part of the area protection"; they are (were? will be?) part of the API; they were used by area protection script(s) and by other LUA scripts (portals and my TELevator, as I know of). I hope they will be part of the Java API too or replaced by something equivalent.

Am I overlooking something or in the new API there is no equivalent of the 'old' LUA Player:createAreas(), Player:showAllAreas(), Player:hideAreas()... methods?

Are they going to be implemented later or have been they replaced by something else I do not see (WorldElement?) ?

EDIT: same for Player:enable/disableMarkingSelector()...

During this relatively quiet time, I spent some time on ETS 2 again and, behold!, I could make it to work!

In short, it was a matter of locating the 'real' app directory (which is not the same where most other Steam apps are located), finding the config.cfg and turn full screen off. Now, everything seems to work nicely!

I am glad I can use it, but at the same time a bit disappointed as I discovered that the world is not 'real size' but compressed: going from Milan to Turin takes approx. 2 hours and a half in the reality, but in ETS2 it took less than 20 min.

Maybe I am spoiled by my previous jobs in the flight simulation field, where everything is and MUST be 'real size': flying from Rome to New York takes 8 hours, as in reality! The realism of the scenery is not important (and I spotted some naïveties), but in a driving simulator at least routes should be REAL.

Anyway, nice app!

Quote from joni909

i hope there'll be some form of functionality too

As far as I understand, custom 3D objects could be acted upon like the [F] key now acts on built-in objects. The plug-in which placed the objects would be notified and react accordingly, for instance, opening / closing the shutter or taking a 10% of health away from the player ("You pinched your hand in the shutter, you clumsy!").

Quote from joni909

over all good model

Thanks, but I know my limits...

While we wait for the API for custom 3D objects to be implemented:

(which, in its simplicity, is already a very advanced achievement for my 3D modelling skills..!)

Just for clarity, I have added another example at the OP.

@botchikii: selon le forum, tu es français (ou quand même en France); tu peux écrire en français aussi, si tu préfères; je croix que j'irai répondre en anglais, parce que mon orthographe française n'est pas grand chose...

"the final orientation of the beam is the same": exactly, this is the problem! It should not be the same. Rotations are not (should not be) commutative; if they are, something is going wrong. What I suspect is that X and Z rotations are applied to one coordinate system, Y rotation to another.

Quote from botchikii

Just try to reproduce that and all work like intended (tested few times with changing position too)

Not sure to understand.

1) What should I reproduce to have everything working as intended?

OR

2) You reproduced my description and your results match mines? In that case, I doubt, the difference between A) and B) on one side and C) on the other side was "intended"; to me seems a structural inconsistency, which makes some orientations impossible (or very hard) to obtain.

@botchikii: I am not at all a "wild life person" (I fled from busy and noisy cities, but I am content of a very domesticated country side!), but I really appreciate your perspective and the points you raise.

AI of NPC is surely going to be reworked; the current focus seems to be on dungeon mobs, as dungeons are going to be released soon, which would be a rather peculiar kind of AI. But, one can expect this rework to gradually be extended to other NPC types, like wild animals.

AI is actually a misnomer: there is no intelligence involved (except for the intelligence of the developers, of course!); so, we cannot expect in the game the variety of reactions we (well, you!) can observe in reality. Some improvements toward reality would be great, though.

Suggestions for taming and husbandry have been raised several times; I have no idea what the position of the dev team is about them.

In the real world, a distinction has to be made between taming and domestication. You can tame a wild animal (of appropriate species) as an individual and you can 'use' it for some tasks with reduced inconveniences with respect to the original wild behaviour. Its children will be as wild as their parent originally was, though and would require to be tamed again (no real idea, but perhaps sheep may belong to this case and, to some extent, horses?).

OTOH, domestication is a process by which a species gradually evolves and develops evolutionary behaviours of familiarity with humans. It does not simply takes "more than one generation": it takes millennia! Dog is the paradigmatic example.

While some time compression would be acceptable in a gaming context, I have the feeling that domestic animals would be better added as separate kinds (for instance, wolves on one side and dogs on the other).

In any case, I appreciate your observation that interaction with wild life should not be limited to killing; any moral consideration put aside, it would be a great waste of resources and of opportunities.

Just read Steam page about Höme Improvisåtion: looks crazy enough to be interesting and fun, for another Ikea victim like me... Anyone actually played it?

Sorry, I do not know German and I read the question via Google Translate. If I understand correctly the question, yes, plug-ins can both get and set the permission group a player is assigned to.

Either I am overlooking something too obvious to find it mentioned or there something strange in how planks and beam rotate with the New Construction System.

It seems to me that:

A) With the [Up] and [Down] arrows, the element rotates around its own X axis

B) With the [PgUp] and [PgDn] arrows, the element rotates around its own Z axis

C) With the [Left] and [Right] arrows, the element rotates around the World Y axis

_______________________________

[ I ] Steps to reproduce B) and C):

1) Start with a beam at reset rotation ([BackSpace]) and default setr
2) Rotate it of 45° around the Y axis (3 x [Left]): the element rotates around the World vertical, with coincides with the element Y axis (no other rotation yet)
3) Rotate it with the [PgUp] or [PgDn] (Z axis): the element rotates around its own Z axis
4) Reset the rotation ([BackSpace])
5) Rotate the element of 45° around the Z axis (3 x [PgDn])
6) Rotate it with the [Left] or [Right] arrows (Y axis): the element still rotates around the World vertical (World Y axis) as in 2), and not around its own Y axis.

By replacing [PdUp]/[PgDn] (Z axis) with [Up]/[Down] (X axis), one can see that also A) above is true.
________________________________

[ II ] Another example:

1) Start with a beam at reset rotation ([BackSpace]) and default setr
2) Rotate it of 90° around the Z axis (6 x [PgDn])
3) Rotating it with either [Up]/[Down] (X axis) or [Left]/[Right] (Y axis) rotates around the same axis: the object X axis and World Y axis.

Now, rotation around two different axes should not be the same, should it?

My mistake or an inconsistency in the code?

One (semi-)official source for the 50cm block size might be this one (but I was actually remembering a different one, probably in English).

EDIT: sorry, @Deirdre, but your explanation using the plank max length either looks circular or simply postpones the issue: yes, assuming the plank max length is 3 m, it is possible to deduct the block size from it; still that assumption has to be grounded somehow...